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

Yunfei Ma <> Mon, 14 December 2020 23:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FC453A1119 for <>; Mon, 14 Dec 2020 15:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 UIWxHjWvoaDS for <>; Mon, 14 Dec 2020 15:26:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 593DB3A10E4 for <>; Mon, 14 Dec 2020 15:26:59 -0800 (PST)
Received: by with SMTP id x26so9995662vsq.1 for <>; Mon, 14 Dec 2020 15:26:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zRc+ZDnnBSSMCbkmHnHiO9cX3Jm2k3D6BrdUZ6D9/eY=; b=LAsCNMB4kOHECVR4deCpByTHvOtirpuvCZ12/tYM5bXj07NocxB2KjiuxUHk59bTFN ATZDTXPx01OBhy5vobAJIhBJNkY8JMRH4gBFY344p96d6EB7NctQGSO3PpFGk8wm4Q1P dme7avwul2E785N/NgZ/OR9zdGAVnUqv7NvSUTsDzTKTOp/sg+ntrdHvJNqe/372Mt5X W/HwFOyRzrghqZ2OIsszwB60U98yRbarmRIqP8SAVWKz1Zz/bSvy5X0wBHvwojv4oLpF vxTOYmvLE97iNXcQ7tY59weNAT64Yamlgl39YbTWFIIgEuVBUmegsjCkr4LSCquEEjcZ mTkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zRc+ZDnnBSSMCbkmHnHiO9cX3Jm2k3D6BrdUZ6D9/eY=; b=hvFKQnqMfjfZRbwTo9z/nF9zysdceVCoBcgyAYvgIkROt28WASc3IxTuxsy+1r1nBX asRvFMvvjdHtrltZeRT+40jU1IkqQivWgOuO3IZD2Og2BZB4STD+1s8KJMxCdcct9LCi kvHpHaEEFdxBz81tKhDJ6MLnm5TwgyND3L8tKs+c1dadArSisIYCu797DP5i+6Rl2FPH XO5e/zdSxwhZ7Uj0+ryn5FzBDTI1K8aVIShFuBwutUzhPGsmTIobarh8PJRydImQk7cz UW6FoojKFrwNyOkZ38ytkNrZLVDLVWtOnlezpd/CXKqktrC3L+jxvgJtNZAXKmTerWbY kYvg==
X-Gm-Message-State: AOAM530D4DUs/KeoDCrggLDyVOcu4V534uyVxCG1Rp2D4lWLtruh5MrZ 2sD14utEoW2/UO1aVnN02Mw9iSHv4Wu4Nyiclyc=
X-Google-Smtp-Source: ABdhPJxayQJxZtiTgkwp9snREt5HtXxTuDASRDqA/7Ulaf+yVWHIIRoVWXR/WMKrlvxFzk3KwEce/LWsOWSxr6BnmwE=
X-Received: by 2002:a67:f14f:: with SMTP id t15mr25858874vsm.0.1607988418284; Mon, 14 Dec 2020 15:26:58 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Yunfei Ma <>
Date: Mon, 14 Dec 2020 15:26:22 -0800
Message-ID: <>
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: Mikkel Fahnøe Jørgensen <>
Cc: "安勍(莳逸)" <>, quic <>, 李振宇 <>, Yanmei Liu <>, Christian Huitema <>, "Ma, Yunfei" <>
Content-Type: multipart/alternative; boundary="000000000000798df505b674fa57"
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: Mon, 14 Dec 2020 23:27:01 -0000

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.