Re: "Proxying" multipath usecases and application scheduling

Paul Vixie <paul@redbarn.org> Mon, 24 January 2022 20:33 UTC

Return-Path: <paul@redbarn.org>
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 23EC53A09EF for <quic@ietfa.amsl.com>; Mon, 24 Jan 2022 12:33:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level:
X-Spam-Status: No, score=-2.802 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, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.org
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 E9i2g-dAoVmo for <quic@ietfa.amsl.com>; Mon, 24 Jan 2022 12:33:45 -0800 (PST)
Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::4]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE953A09ED for <quic@ietf.org>; Mon, 24 Jan 2022 12:33:43 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id 38FED125FD8; Mon, 24 Jan 2022 20:33:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1643056420; bh=HPez9QnJoqzu8ewUZjQo9odLRrxsnMeQ8HIKmHac0Ic=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=T830VVudfCbEE5zzUxGP7jua506zvC5Sg5mrDIxBffoHy1ZcliLidaP1qtnLl6296 IhM59OqA/yVaBPA+qcIMu9YYlUh1BQWTfJIjIz5aIdNN4W2wepMFdKK3TjmlPDhff8 YvWF+fHAjlcJIOnUN4AQzkvzVubM9lRsLuoYiWnM=
Received: from [24.104.150.172] (dhcp-172.access.rits.tisf.net [24.104.150.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id CC2EF7597E; Mon, 24 Jan 2022 20:33:39 +0000 (UTC)
Subject: Re: "Proxying" multipath usecases and application scheduling
To: Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>
References: <DC26182E-5547-455E-8254-611A5939B9F0@ericsson.com> <2BEDB49C-BA89-4E50-9738-3818B3D7C7D2@erg.abdn.ac.uk> <17562bf0-926e-35d1-c4be-c0692582fe54@huitema.net>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <9c267c15-5ed0-9d3a-6ba4-e57ca63755a2@redbarn.org>
Date: Mon, 24 Jan 2022 12:33:38 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.54
MIME-Version: 1.0
In-Reply-To: <17562bf0-926e-35d1-c4be-c0692582fe54@huitema.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/bBfgvqu9JId4Kq246DSWeF8HwnM>
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: Mon, 24 Jan 2022 20:33:50 -0000


Christian Huitema wrote on 2022-01-24 12:15:
> ...
> 
> Like others, I have mixed feelings about the kind of proxying proposed 
> in the 5G design. It does look like a power grab by the telecom 
> companies, force all user traffic through a telco managed proxy, getting 
> an observation point to see all the user traffic, do all the kind of 
> "statistics" we could expect in these days of surveillance capitalism, 
> and be in a position to control how much bandwidth is allocated to 
> specific content providers.

i think calling it a power grab when it's done by an internet transit 
connectivity provider (such as "the telecom companies") makes sense, but 
that without clarification, could connote untenable meanings.

managed private networks, such as enterprise, government, university, 
small office / home office, and home / family networks, already have the 
power you describe, and will preserve the status quo at "whatever cost" 
the ietf may impose.

i pray that we will consistently disambiguate. there will be no wide 
area UDP on most managed private networks. we can either pressure these 
networks with endpoint failures (to strong arm them into abandoning 
their historic powers), or we can rely on fallback (which for new 
protocols may be more fragile than for the existing WWW), or we can 
negotiate, in ways approximately alike to the "proxying proposed in the 
5G design". those are our choices -- there is no fourth way.

if the ietf wishes to disintermediate on-path actors, then we ought to 
consistently and carefully identify where the power is (managed private 
edge networks, and endpoints), and avoid antagonizing those power holders.

> The only good effect is that proxying will 
> hide the actual user location from the content providers, which removes 
> a bit of data from the surveillance capitalism dragnet. But overall, 
> that's not great, and I would rather not have a feature like that on my 
> phone. But hey, that's my opinion, people may differ. And I wonder 
> whether that has much relevance to IETF work.

if the ietf's mission is to impose societal change, then explicit 
negotiated proxy service may not be relevant. however if the ietf's 
mission is to create technology that supports generally desirable work 
flows, then proxy discovery/negotiation is vitally relevant to that.

several networks i operate and many that i'm aware of will have to do 
content inspection. there will be no free lunch for IoT (which is an 
instance of "surveillance capitalism dragnet"). the ietf has to decide 
whether to oppose, or ignore, or cooperate with that reality.

-- 
P Vixie