Re: "Proxying" multipath usecases and application scheduling

Watson Ladd <watsonbladd@gmail.com> Tue, 25 January 2022 13:44 UTC

Return-Path: <watsonbladd@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 5A43F3A121C for <quic@ietfa.amsl.com>; Tue, 25 Jan 2022 05:44:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 gmgl34y1Tyok for <quic@ietfa.amsl.com>; Tue, 25 Jan 2022 05:44:43 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 B80FD3A1216 for <quic@ietf.org>; Tue, 25 Jan 2022 05:44:42 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id b13so62960851edn.0 for <quic@ietf.org>; Tue, 25 Jan 2022 05:44:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/P/q03XsBJwSwf1qCVJRczWibAlk5c8+hwohBHx/EJo=; b=Z68Yjx/NA9eQnnkp0Z6UK4lkAXjf2a32saAnbT0TnZUouNytEvW9VLdkcwotP4MWzM 7Pg+uWM8dzDXziI40JiM5RIyZ8VQQRslWMb84//D0wKCL7sfY3SHEaTBoW9oupRkrOva UeVqor8jTqn7NNOTC0A+BN1e3YNMDlcyDGjehaoAs7YV2r2GnbG29uZ/FqRBHuzYPTY7 pJgZ8Px5dm5OdAnqvpXGrB95R9/W5puD3PAp3AvpzaDEA6Kg5UfjtAihFasNCY+2tVzW KoiNBUh8epxNOj9SDEJ5ijee+u4ztGnrc/MDc6GknejGfvjdfpLZ+lOkN6TeV0/ERSYm zz4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/P/q03XsBJwSwf1qCVJRczWibAlk5c8+hwohBHx/EJo=; b=Y/N+jvIROGy6kS78Knmi+BLrnsyw283zZjZctJeokBHav4DfnC25lBJkUBimkLMUjK VHk8xxq+7foJ424fZB7UvoOQUGQ7dD5cP44WrKisOHtQFAD1Kp4P/4fKuO2K3SK0G4YE uh/7cSNJGeQmeNJy9pDerRR/ebdbuSKHgcm3oICNFDx/DUDmVWWM87MTaXgwP8albeuW Mu/K+cByc3Pp5QuLN/5R5SIXUMVrwCr0DwkNuZCzBsE62Lo7MvOJyNqJy4W79zf6FQqa 0chvcU82Oda6PK5F4lxvhIZLoKAlDcJzeHq5UV2IPYDB8cqFm1HjI2xSZ0aYa//qSGsa G4tQ==
X-Gm-Message-State: AOAM533SlfUemezF+IZdxXhP8uY3MrKNz6FsCuFnfsMg6UStOhrT1STc txX3XD7TQbOklvelES2eBxKUvq8HBcoHCM5Czho=
X-Google-Smtp-Source: ABdhPJx6ykE3nb+iFzm6DnxYTjwEw0fXB9GZROVIwtBbnoMvkmb+bulFhjBbOI+PvKFbWM8jWQnlRmEFsRb5t+3gBNw=
X-Received: by 2002:aa7:d3c2:: with SMTP id o2mr20917462edr.207.1643118279675; Tue, 25 Jan 2022 05:44:39 -0800 (PST)
MIME-Version: 1.0
References: <DC26182E-5547-455E-8254-611A5939B9F0@ericsson.com> <2BEDB49C-BA89-4E50-9738-3818B3D7C7D2@erg.abdn.ac.uk> <17562bf0-926e-35d1-c4be-c0692582fe54@huitema.net> <9c267c15-5ed0-9d3a-6ba4-e57ca63755a2@redbarn.org> <CAPDSy+7TQspbw=aM0LMt8A6R52d2YH5FyHZxbBonhTUFN0r_AQ@mail.gmail.com> <9a3ce8d9-de6b-b2d2-b960-f2b699b84785@erg.abdn.ac.uk>
In-Reply-To: <9a3ce8d9-de6b-b2d2-b960-f2b699b84785@erg.abdn.ac.uk>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Tue, 25 Jan 2022 08:44:26 -0500
Message-ID: <CACsn0cmkyNoCpcpXQ+JCU5-uJ-EpN0EAug9WDQHDcsGEZGeZjg@mail.gmail.com>
Subject: Re: "Proxying" multipath usecases and application scheduling
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000062524805d6684965"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/9RlHUfuJcI9fQBVcEubjhIN1Hp4>
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: Tue, 25 Jan 2022 13:44:47 -0000

On Tue, Jan 25, 2022, 5:00 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:

> So...
>
> I've added something at the end, to note agree on the priority...
>
>
>
I'm really not sure I understand how these usecases are indended to work
and will complicate an already complicated enough protocol. In particular
discovering the indended proxy endpoint seems like a ball of wax. Then we
have the issue of ossification as well as the privacy impacts of at least
some of the proposals.

> Other people have now mentioned enterprise networks; 5G (using a variety
> of sub-IP technologies) and IoT, there are probably more.
>

I'm not really sure that these are the same problem. Advertising multiple
subIP paths isn't the same as network based management, which really should
be done at the host level. And ECMP in the network is a thing. It's
possible to imagine opportunistic multipath that changes the 5 tuple hash
to obtain multiple potential paths.

In the case of satcom where FEC and retransmissions due to consistent
packet loss together with bad latency are challenges for loss based
congestion control the case for a proxy is a bit better assuming we can't
succeed in having better congestion control algorithms.

Sincerely,
Watson