Re: New Version Notification for draft-dawkins-quic-what-to-do-with-multipath-03.txt

Mikkel Fahnøe Jørgensen <> Thu, 07 January 2021 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11B7B3A0062 for <>; Thu, 7 Jan 2021 09:17:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=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 xSfdC9yJiUDi for <>; Thu, 7 Jan 2021 09:17:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9D9E3A00C4 for <>; Thu, 7 Jan 2021 09:17:08 -0800 (PST)
Received: by with SMTP id o19so16382952lfo.1 for <>; Thu, 07 Jan 2021 09:17:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DqBZqooI9vZJEECNymYhKzzHpAzL2njcMc0cqf+7EMo=; b=UJNxNcnpjMZ9jMt+ZJJI+9pZc5RGTITUl+NOwzK+mzF7KkwyExKIELvDWn0kH+UOxm WuPuDK/OlatYOEoFZCLVJtB8X1W6yyPYqFN9JGPKfiOgMM1zoJDuN6x0q0lvxJrI061m HZJJ2RBZ+m5qbbAztwcWFB4GVnA5gsPP9GQ2jWO7+5TYHOpTKDXq9HdPhudb/gPawhxk gO7PPfbFuMPDA11l8RbfYJT/MCLo/VktWABHWysQq2d8wAdqTYdeXRvgAgqjsPRXBDEw Lyrmw00eErTL/ceEC2aEIUEiyZ8VWCbsBNZ83oIKJ84/CST85eoC4PlV3K6Hs2eLWX96 yYIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DqBZqooI9vZJEECNymYhKzzHpAzL2njcMc0cqf+7EMo=; b=RNCoo8SNHHx/wYb6Znib7QMpmXkQ/4l1+DuWcxZt0Ya04FOdLpyeMd5wdDrTrxLSER S1O6hQdSdzdtGM242Twv4atADngCc4AO20ajuMDn7kvccd4VXdNJilfJmJgzgYcVpWXm BClDAOCRp/62SWClUsbLcBeyrRCEpM1fgW+yHBGyyUCuUrWLHLdexhNvHYo3pW5VN6bN FdE+Fm7D7wC2LbEGSXwUj/Ntydvzv05wg4n2K4odqSBTDZzSDxepuMSvA4CpdB59P0r1 iY0U2lpm9IMx+kgxlRFnV/CKYpusJuCv++zLz9/nXGe3EzwIZYNqjzxIXrEEJdbMdgB6 Fdyg==
X-Gm-Message-State: AOAM533yyDHqhEljm62Dm5/QB2mo/RmfuJYknTrpFHpEdV2/p+qfM+Mh MPYcIEQud1nMXM5pwbZhmRw=
X-Google-Smtp-Source: ABdhPJxpjlg0uyE/H93P8lqwI8wE8B/d5iG1KzttNjf+BLT7YaFx1WQ1KvqZysd6ssUNx/eRH3VPbw==
X-Received: by 2002:a2e:89d9:: with SMTP id c25mr4977176ljk.410.1610039825242; Thu, 07 Jan 2021 09:17:05 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id w13sm1385948ljw.28.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 09:17:04 -0800 (PST)
From: Mikkel Fahnøe Jørgensen <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A6B2F9C2-31C3-4459-9449-3A839593AFE8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: New Version Notification for draft-dawkins-quic-what-to-do-with-multipath-03.txt
Date: Thu, 07 Jan 2021 18:17:03 +0100
In-Reply-To: <>
To: Spencer Dawkins at IETF <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
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: Thu, 07 Jan 2021 17:17:11 -0000

Great work.

From a quick read, I believe you have captured many relevant use cases but perhaps the document does not capture the concerns related til NAT translation and firewalls.

There is a diagram showing multiple paths between two QUIC hosts A and B, and I think that is great because traffic between two data center hosts is a great use case IMO. But here hosts can mean anything, also a mobile client or a user at home or at work behind a NAT router.
The use cases and trade-offs differ significantly in these separate configurations, and the problems are also different in that it can be hard to maintain or initiate a path in reverse direction of a NAT.

Apologies if you already made that clear in a section that I missed.

> On 7 Jan 2021, at 04.26, Spencer Dawkins at IETF <> wrote:
> Dear QUIC WG, 
> I'ave gotten some feedback on this draft from several people, including several presenters at the QUIC multipath virtual interim last October. 
> See the diffs for details. 
> Just to be clear on something that's probably confusing - I'm trying to capture what people are trying to do with multipath, based largely, but not completely, on the presentations available at <>. So I'm trying to capture the state of play as we started having a serious discussion about multipath. 
> I'm also working on a draft that tries to identify the questions we've had come up in working group discussions. I'll probably submit an update on that draft tomorrow or Friday. 
> I hope these are helpful as we move things along. 
> Best,
> Spencer
> ---------- Forwarded message ---------
> From: < <>>
> Date: Wed, Jan 6, 2021 at 9:18 PM
> Subject: New Version Notification for draft-dawkins-quic-what-to-do-with-multipath-03.txt
> To: Spencer Dawkins < <>>
> A new version of I-D, draft-dawkins-quic-what-to-do-with-multipath-03.txt
> has been successfully submitted by Spencer Dawkins and posted to the
> IETF repository.
> Name:           draft-dawkins-quic-what-to-do-with-multipath
> Revision:       03
> Title:          What To Do With Multiple Active Paths in QUIC
> Document date:  2021-01-06
> Group:          Individual Submission
> Pages:          14
> URL:   <>
> Status: <>
> Htmlized: <>
> Htmlized: <>
> Diff:  <>
> Abstract:
>    The IETF QUIC working group has been chartered to produce extensions
>    that would "enable ... multipath capabilities" since the working
>    group was formed in 2016, but because multipath was an extension,
>    work on multipath, and the other extensions named in the charter,
>    waited while work proceeded on the core QUIC protocol specifications.
>    After the QUIC working group chairs requested publication for the
>    core QUIC protocol specifications, they scheduled a virtual interim
>    meeting to understand the use cases that various groups inside and
>    outside the IETF were envisioning for multipath with QUIC.
>    As part of that discussion, it became obvious that people had a
>    variety of ideas about how multiple paths would be used, because they
>    weren't looking at the same use cases.
>    This document is intended to capture that variety of ideas, to inform
>    further discussion in the working group.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at <>.
> The IETF Secretariat