IETF Logo Mail Archive

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

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 16 December 2020 10:27 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CA73A08AA for <quic@ietfa.amsl.com>; Wed, 16 Dec 2020 02:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhVuOK1ZBgWU for <quic@ietfa.amsl.com>; Wed, 16 Dec 2020 02:27:39 -0800 (PST)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578493A089A for <quic@ietf.org>; Wed, 16 Dec 2020 02:27:39 -0800 (PST)
Received: by mail-yb1-xb30.google.com with SMTP id y128so2242856ybf.10 for <quic@ietf.org>; Wed, 16 Dec 2020 02:27:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=nynVyBeSQwmb6v7QG4u2mX2D4DpWMf3k7psHqUdL0zg=; b=MoA/fuznXL9SXCoKYziH4XN+5SMr09StM7gL1FS39AGOMZ5JjCrRtb4DhAA3xbIKM8 TdG7Y0mTq+s6Hivl3CE27tAquPxtXEh2x6iT4CGSM0Gc3zaZOwbdI8Xxo/zKc7HXml/s S3YuPWnMb8kUS9jKMwZGL1dCjsspy0i7ac1lcTJRn8AqS6WKXJAO2x81FKZHruSDREGt l4OeG5PSwmE/r309fN69j/yTz+HADrnfPGmi7nwrt+GnPLx6czvWFG15Y8GW5pZmjbn7 BuliqG4JtdQ9z70MzpOw6yhSVtehBkGh28uS7rEBfOXtmWeXZ0a8zPTf64jeFpaDxqZw ZWcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=nynVyBeSQwmb6v7QG4u2mX2D4DpWMf3k7psHqUdL0zg=; b=fiQlyq9KR+mVL+BkWllcsTH2jJsqz99gMN6e36tR192WziO/9h2bzZDzU4yA523ONU eNLOTALy9iB9DLqCzrbXjnuAEHNtZ0rNcXB3N/GlaBzBbXGEpfBoiDsPLKO9fvuYuHYz IJpwHaf5anPjk/9EPRr5HmHvCHOYPef7QcgDGND1bBDt5FlPPyuZp+4RcpLEAWJi6E1d oXXMl3VmL/QSkQJ54nB7OWEplB8Xq1R4z0FpdlM2own/uyE4OVsVPKP7YYViw/SEGZaD GX0j+mZkVEG5b5xAK8LvuKtefV46QE/OkVE22fham2rHnDjayu2eas+vx9+u7SPSntbx fZzw==
X-Gm-Message-State: AOAM533gHnpawo2LJWKjYG4QSFKewR2OFEFRJvraLD3cNUBZGkr4kxPG SM5BitQxnyO8V72yySRTUPwNnS7uQODqKrKmYvs=
X-Google-Smtp-Source: ABdhPJwr9BT+tFAYKDMm8Xlcn19AU/m1IzICE9+JZ0ZSMM8xTrJ8Flq7LFgIc4/1Gedrj2Owamwfc0GIQNsDjIH0vUA=
X-Received: by 2002:a25:6c8a:: with SMTP id h132mr28862211ybc.263.1608114458493; Wed, 16 Dec 2020 02:27:38 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 16 Dec 2020 02:27:38 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <4345423f-c639-2c03-e726-6dcc8d58ea0e@uclouvain.be>
References: <1baa86a9-455d-4256-85f2-9aee159afed9.miaoji.lym@alibaba-inc.com> <e8027334-2615-30fc-c4c4-e890c5f527b8@uclouvain.be> <CAHgerOGXWgfna8DmGYGnSYESyuJNseWmVSZquyuY9_WUf30nbw@mail.gmail.com> <CAN1APdcH1Jh4BpCiq_xuzb6s0a++c9Ty4ebaYBZvtsqbVcQStg@mail.gmail.com> <4345423f-c639-2c03-e726-6dcc8d58ea0e@uclouvain.be>
MIME-Version: 1.0
Date: Wed, 16 Dec 2020 02:27:38 -0800
Message-ID: <CAN1APddRfV46_JdAEGWmO00TCt7pZqiEknSp-RCS3yOE-+syOw@mail.gmail.com>
Subject: Re: Fwd: New Version Notification for draft-liu-multipath-quic-01.txt
To: Quentin De Coninck <quentin.deconinck@uclouvain.be>, Yunfei Ma <yfmascgy@gmail.com>
Cc: "安勍(莳逸)" <anqing.aq@alibaba-inc.com>, quic <quic@ietf.org>, 李振宇 <zyli@ict.ac.cn>, Yanmei Liu <miaoji.lym@alibaba-inc.com>, huitema <huitema@huitema.net>, "Ma, Yunfei" <yunfei.ma@alibaba-inc.com>
Content-Type: multipart/alternative; boundary="0000000000000e87b005b69253a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/3gn0xf9hMXeEaP9rw4C2Z75REcw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Dec 2020 10:27:41 -0000

In my opinion, I don't think the "path" should be the element we should
identify. Rather, I think we should identify "forward flows" and "backward
flows" (what we call uniflows in our deconinck draft) and see paths as a
combination of a forward flow and a backward one.

Maybe - it sounds appealing. But if the client is always responsible for
probing paths also for different server announced endpoints, then both
endpoints are naturally coupled. The alternative would be for the server to
also probe paths, and that can be difficult with NATs without STUN. There
are many things to consider ...

Mikkel

v2.23.0 | Report a Bug | By Email