IETF Logo Mail Archive

Re: Privacy considerations of multipath (Re: My BoF report: multipath)

Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 02 December 2020 17:38 UTC

Return-Path: <lucaspardue.24.7@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 B61153A14AE; Wed, 2 Dec 2020 09:38:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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: 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 g47azk3of71G; Wed, 2 Dec 2020 09:38:06 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 B91723A13EB; Wed, 2 Dec 2020 09:38:05 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id v22so4838899edt.9; Wed, 02 Dec 2020 09:38:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qb8yEDbiDgh7FZJ+bGmHT3YiQO4dQaP7eh3yA2zuGo8=; b=nboljnow6GaeplfgEyxuV7rZtEbjpcGwzykjvTSZwbAJbA1z5Oj1LJyhW8+SzTQ3sR RK2ziZH3DRvcm+734p43T5i2dHrhBhnmxzlNyteCCVZA2zgmS+YMBpEV0jsIEUTk4Oeb VZN7XORz2mTqkfgxDITBkixMUZCt3PcUVaV4XZmfLRUT60SOWzNC7A7b2xnk1XoCXnAF A1w9SWmqFsFFgO5b7MRwf0J2MK8spRa5OWegI0KQogSFktFC8lbh+zkqxA8vW1C+MvTZ U1DOZn1ILtCcgYDy3Ct0lWCdZAJex7SoArXYOxLLNx4Zg+uPBf9CDQonU6nnyKap0X5/ SjXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qb8yEDbiDgh7FZJ+bGmHT3YiQO4dQaP7eh3yA2zuGo8=; b=HU7olUyTt9zmKp3uXZiHIJ6pSy9NwVulJMHSH9ZxF8mMCrdMffm9Ca4v2b1KIApw90 sViGPU8fsbO7dWQ4Mwua0Vet43QtEWZj2860iAcgx307l3OrjrZYO4W0+xsrCRyrye7e HDO12lNODnfsilA+ZYUjFNhACrC85svSpB78X+WSmWEmgv9VLw6QgCteVRQNXEMFh7+E dLabIDGDh7BHtvb4FH+NR/sHlPtgHdES2A77xoM2o8oJswanhNv9PJTGlDlPYZQSeDF+ aAVhJm0CX2Ydcv3awutMEZK5wuvlMu3msv7CtQFuGshh3G6jULJVtjUg6ESkyAdi6IW8 zcSQ==
X-Gm-Message-State: AOAM531wQmIAxrtPMXX5UMiY6Rjg7gxFRpwgK9aT2v5rQC7C01fsikSP pnnw9MPXdjyVXYzYZFIbmB0HEBQnzvLURZ3QqRs=
X-Google-Smtp-Source: ABdhPJzDlihR6IwZnOAoFCIzQRb9z7Jl6+MnJKIClSUQuyKQ5y2TKvNrP8PPVKn6XKVOA+jBp0CwLvUD8xGkRQM8H6M=
X-Received: by 2002:a50:8f06:: with SMTP id 6mr1026176edy.39.1606930684009; Wed, 02 Dec 2020 09:38:04 -0800 (PST)
MIME-Version: 1.0
References: <d84c82b1-fa67-4676-9ce2-d2a53d81b5f7@www.fastmail.com> <5741601d-7e67-898e-5840-70feceb994e9@uclouvain.be> <CALGR9oZW0s6c6+N+3R8bD17yPBPQa4E_cVOaTOSNTVQPYy6sUg@mail.gmail.com> <CAC8QAcditJ0nzdCNHOhi-1xtezoXb0u=hrGBWtZ3Cj3XP6CW4g@mail.gmail.com> <CALGR9oZfw5LqfPyZw6Yb8JTmuqi0prTL0f0yT9Rdq6oz5u51fg@mail.gmail.com> <ccbd3f9a-883e-6262-5735-2b9f25c6c6c4@zinks.de> <CALGR9oaw_-dbYSu5oN1Usvwr2h8wp-gvcmzx+0+2HJM-4Ac+4A@mail.gmail.com> <c09ff2f3-771b-11df-68f3-c690efa998c7@zinks.de> <CAKKJt-exKQa8o6Gn1=-SdDFQSrRGMtDsWJy62=RAQMD_T=P7ZQ@mail.gmail.com> <818d4f85-faa6-110c-7a94-441d7fe53166@huitema.net> <CALGR9oZzznU9qTc-T6xVYJOOT4cEhC8tunYK94x+HkQNmHFvEg@mail.gmail.com> <BF0B6222-AA56-4B8C-B0C2-FE06D4761009@apple.com> <CALGR9oZEpTCVAyff7c6m94H+U9qsNNU=wc39=hdKeZ40nqHvxw@mail.gmail.com> <8D47043C-7401-4188-B1CB-0D920F566798@apple.com> <CAKcm_gNJxx35urnjttP5LdY-iVki-R5Xuh4iRHC-gGTnO8sTXw@mail.gmail.com> <ED60506E-B4FB-44E1-815D-76EE5779D674@ericsson.com> <CAC8QAcd4z5Yqh2xV_V4bsrrQecFbBZ_juz-GtksDbDwd0ecttQ@mail.gmail.com> <CAKcm_gODh_krHES7iJCP4MvS2YatHykzPJJTqLQuBgPKT+vFcw@mail.gmail.com> <CAKKJt-d43kVJTHcByBQy4pErf4QuNLEsajpfv_Pfo24kX2qwfQ@mail.gmail.com>
In-Reply-To: <CAKKJt-d43kVJTHcByBQy4pErf4QuNLEsajpfv_Pfo24kX2qwfQ@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 02 Dec 2020 17:37:52 +0000
Message-ID: <CALGR9oanTr5NNmJcOJnFJiZguszPx927w6UW6HqeWop9Njh3zw@mail.gmail.com>
Subject: Re: Privacy considerations of multipath (Re: My BoF report: multipath)
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Ian Swett <ianswett@google.com>, sarikaya@ieee.org, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, Eric Kinnear <ekinnear@apple.com>, Roland Zink <roland@zinks.de>, "taps-chairs@ietf.org" <taps-chairs@ietf.org>, Christian Huitema <huitema@huitema.net>, QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000099615c05b57eb4b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Y2mDRa2I2ujRvtf1EZn-kfzgxAc>
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, 02 Dec 2020 17:38:08 -0000

Hi all,

Just a reminder that this thread, and Ian's comment that we're picking at,
predates the "Next steps for Multipath" email that Lars sent on November 20
[1].

There's levels of nuance here: a self-test experiment, interoperable
experiments in developer environments, experiments that emulate a
production-like deployment, experiments on in-situ production equipment,
and so on. Interest, ability and time in all of these levels is not
universal.

So my _personal_ take is that folks would like to establish confidence in a
multipath design, as if it were deployed in the production environment that
it is intended, before adopting it as a solution. We've seen before with
stream priorities that a rush to design a signalling mechanism, while
punting on scheduling, can result in defining something that is not
generally useful - the antithesis of standardisation. I think it's fine to
have the logical separation between signalling and scheduling but the
practical engineering reality is that they get deployed together.

Cheers
Lucas

[1] -
https://mailarchive.ietf.org/arch/msg/quic/rcPf7u9AHIGwNr6j0ZqrqFujVvk/

On Wed, Dec 2, 2020 at 5:08 PM Spencer Dawkins at IETF <
spencerdawkins.ietf@gmail.com> wrote:

> Hi, Ian,
>
> I'm not Mirja, of course,
>
> On Wed, Dec 2, 2020 at 10:29 AM Ian Swett <ianswett@google.com> wrote:
>
>> Thanks Mirja, that deployment setup sounds like it could make it
>> difficult to get deployment experience prior to publishing an RFC?  Given
>> the complexity of multipath, shipping an RFC without deployment experience
>> seems unappealing to me, but maybe there is an opportunity to get some
>> deployment experience earlier?
>>
>
> At least some of the presentations at the October virtual interim on QUIC
> multipath were not 3GPP ATSSS-related.
>
> I agree with Mirja's point on the difficulty of obtaining experience at
> scale in a 3GPP network for an experiment, but I'm hoping there is enough
> commonality between other people interested in multipath and QUIC that
> SOMEONE will be able to report experiments for a proposal that would also
> work for 3GPP.
>
> That's one of the reasons I started working on
> https://datatracker.ietf.org/doc/draft-dawkins-quic-what-to-do-with-multipath/
> - to see what was common across people with different use cases.
>
> Best,
>
> Spencer
>

v2.23.0 | Report a Bug | By Email