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

Mikkel Fahnøe Jørgensen <> Wed, 16 December 2020 09:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F8463A048B for <>; Wed, 16 Dec 2020 01:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Status: No, score=-1.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, 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 lrLqyX5ZVu9x for <>; Wed, 16 Dec 2020 01:19:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACE353A0475 for <>; Wed, 16 Dec 2020 01:19:45 -0800 (PST)
Received: by with SMTP id j17so21742186ybt.9 for <>; Wed, 16 Dec 2020 01:19:45 -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=P+ChjI405wxXeOppLiQBJBwxeCYUePVcbFBa8eQiiA0=; b=fGk485t98rrIxzm8gp1ld/QaDJgJ/hKVbxTxQnhOW5puvs6sWJFYGPIrLy5RKvkEPb jx66xjE1yrKz8M0A194DMI14z+Ji8h2i+pkVUyunSKZDtxASc09udkQUu0Ejiqy3tvKQ GCu89BUoiuM0yTWNw7MipKopc6XuGWp2jVWFCTMzl4QA1XCLaz78NWDYVuBqs9cTtDHE dytniPN70iRtVxFKXoVHomp1Qa8ljyLUQgEZAo4lKIgEcQL5Cl09C6OpAJ5XmVRIqvrK mmCLe7NB67wkqZLtaryfSYEO/5PusJHK6/FxsBLi4yazAY3FQHqGfd79DFq6C2/34t0x DuCA==
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=P+ChjI405wxXeOppLiQBJBwxeCYUePVcbFBa8eQiiA0=; b=Ayeu8I99HBbveNdfiNLRCJJ6t3mGqLYYqD++ZvCxXTe0KykfFtz8UNPF8BlghWKnr9 BDGpeS6EMvjOtILEp+BBs834UoNhaU4tsAr99liC0+4o44es0UzCWzy/NPgroripTShX HOAEBIWJBB6aRjU7y5rMMIAEv7tATKMTfxVOUUJs6SvaECSO2TMQhxzyLwqI/8CcNExJ yVQ9Ymf6RC6lDJMwyS7+Oc52qIqf0Ca9LetjPyrc4N0FtEaMXfKmVZltULfShsBLMmQF DaCHP9iFMd665FgJYNmSLiucDxUU8n15gBrGkh5liSOrSWzks6bm5RJy/lTb0N5XqtWB p0JQ==
X-Gm-Message-State: AOAM532Imjx+znQh7IvvlTxAzBsErU2UhWWlBWi8jAPeCuWZS9Ijlio7 vRJd9GbXPGEHEjRk4kQbm4cokE1QrINL4PJJFUbyQPqo45VMkR2u
X-Google-Smtp-Source: ABdhPJwBRHouBLDQDEmEnzoO6heajSdnTAvikamHsifIork8babXH+P9ZkNBK/+cLwSm4DMOhQFCcG91nOzcXQUs3K4=
X-Received: by 2002:a25:2f8e:: with SMTP id v136mr5304337ybv.294.1608110384868; Wed, 16 Dec 2020 01:19:44 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 16 Dec 2020 01:19:44 -0800
From: Mikkel Fahnøe Jørgensen <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Date: Wed, 16 Dec 2020 01:19:44 -0800
Message-ID: <>
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: Quentin De Coninck <>, Yunfei Ma <>
Cc: 李振宇 <>, quic <>, "安勍(莳逸)" <>, Yanmei Liu <>, huitema <>, "Ma, Yunfei" <>
Content-Type: multipart/alternative; boundary="0000000000003ff04e05b6916086"
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: Wed, 16 Dec 2020 09:19:47 -0000

| It also seems odd to create a (bidirectional?) "path" with different
identifiers at both sides.

Hi Quentin, I have not read through your document, as I mentioned in an
earlier mail, I also have some concerns about the the Path-ID being too
granular because QoE does not relate to a path instance (sequence number)
but rather the tuples it runs over - at least most of the time.

But … the Path-ID in Liu uses the sequence number of the client CID.
Presumable both endpoints uses the same Path-ID for the same path, even if
server sends with a different CID. I had some concerns about PATH_STATE
frames conflicting on Path-ID when sent from different endpoints, but that
shouldn’t be a problem. I also especially had a concern about future
symmetric multipath with server announced endpoints, but if the client
always probes the path first, the client CID still remains a unique

Now, I do think that a more stable Path-ID makes sense compare to the
(potentially) frequently changing CIDs. But, again thinking about a future
server announced endpoint, a server might want to use different paths for
traffic steering even if the endpoint tuple remains the same for multiple
virtual paths. The server CID could be computed differently for each
virtual endpoint and affect server side routing.

So I am not sure client side Path-ID should be client CID because it
changes often, but it should be sufficiently unique for both endpoints.
Also I am not sure that a tuple based Path-ID is a good decision because of
potential virtual server endpoints.


On 16 December 2020 at 08.25.34, Yunfei Ma ( wrote:

 It also seems odd to create a (bidirectional?) "path" with different
identifiers at both sides.