Re: [tsvwg] host-to-network signaling requirements

Tom Herbert <tom@herbertland.com> Sun, 17 March 2024 14:57 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FA4C14F5FD for <tsvwg@ietfa.amsl.com>; Sun, 17 Mar 2024 07:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bDQVmz_D8ho for <tsvwg@ietfa.amsl.com>; Sun, 17 Mar 2024 07:57:50 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25ECC14F6A4 for <tsvwg@ietf.org>; Sun, 17 Mar 2024 07:56:51 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5684073ab38so6770397a12.0 for <tsvwg@ietf.org>; Sun, 17 Mar 2024 07:56:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1710687410; x=1711292210; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WLsMDqd4EKeX1ddrvgnWdCKbk5ZNgJ5jlJGX9qTmWv4=; b=cICr3Y5v3apTxp7aSwfIOHo+xszJnpnWcSugl4Y2HvlEJM/9e/sxDC9Ftf5JIFAJvg 00L1hTP2oqHo4PVSImVUMo/112O530sXV5/UT4zncnt3+zJM0KDp0EFOoQNgNLiEB+Po Bhyf1bChd1SlqlFz3GGYo+kv5KAYNnWDPCtTxL2BAm9UaJcDAwwHYaF6uWWLSGs0Qb1c KymXfXJCwMtj5xg8X0Irhn2BjRZDJEGNcsJp8S3I0SlXE3zG/IbNMDYPww65nh8R1I1h btciPKo0lFQAWS3QG6D8yQeIt+WKn2B7UK6IwMJG0nUxIfFazE+fLE6TccHc4rAQOs04 +Fcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710687410; x=1711292210; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WLsMDqd4EKeX1ddrvgnWdCKbk5ZNgJ5jlJGX9qTmWv4=; b=C12rQdmCkGZk+qVGBuoGEfUR91agn558g/QPGkG02jKLzwLVsaLvLtBBek6o9W77V8 Nas/erFAg7YwXElcipCSMXnG7QvUiKdZ+/OgRdYYI2h5qgRkHB5EsvkAk5+TS8hmfVR/ LPQD6GzQA14m6MaRTsDXzO2C8USD02bETduPtmxVHnab3+zgig54y/gIG++RSIf7DjAj ujWrNsp3Ppb/iVr+sm3oWiO7uCoGkVxYPtE2uQ/ktvnONsMSvcTvjpr8pLsI2kLJFW8X M95K2P2SRLlA5KFqjOa/88I8A274Z8ghmbMjT/XjS8nPI59SFwS721Ri/GyuDd6rX4aR CcAg==
X-Gm-Message-State: AOJu0YxNBqDtM0S9sj7ejoakq5a9yBqNIw3o7yBhBwKXTxkOfUeEIrcw BAGskTWouMu54b/mOpLL3BCEPKdK6Lw2nAWsM7PFL+iPjW9Gf/doKyvg6lESt1JO9UT4QI9ukXY wN4YRkZSS7YcW9J6K0whgDCUJdf/Ba4Tc0s4n5U8Krctb5hqpKA==
X-Google-Smtp-Source: AGHT+IFoQxKYYVWJ5LDZTkHmYFfo/af4jPWYw3jLcru0TvPNHoW5MdkEq8U/wo1UEpsMyIscB8IYC2w0haPAUPJEHPA=
X-Received: by 2002:a50:9551:0:b0:568:aced:e5a0 with SMTP id v17-20020a509551000000b00568acede5a0mr6251886eda.14.1710687409571; Sun, 17 Mar 2024 07:56:49 -0700 (PDT)
MIME-Version: 1.0
References: <9B0C7A76-5620-4630-B68E-44D4CCC9E1FD@gmail.com>
In-Reply-To: <9B0C7A76-5620-4630-B68E-44D4CCC9E1FD@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 17 Mar 2024 07:56:38 -0700
Message-ID: <CALx6S360aCDPHD0Ktjw1qbYuqpMSQTpEk5jZU7RZbabd9Pf9_A@mail.gmail.com>
To: Dan Wing <danwing@gmail.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>, draft-kaippallimalil-tsvwg-media-hdr-wireless@ietf.org, draft-rwbr-tsvwg-signaling-use-cases@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/u5HBdRIh99BFke6zUEDY9Ha6t3M>
Subject: Re: [tsvwg] host-to-network signaling requirements
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Mar 2024 14:57:54 -0000

On Sat, Mar 16, 2024 at 8:25 PM Dan Wing <danwing@gmail.com> wrote:
>
> I like the update to draft-kaippallimalil-tsvwg-media-hdr-wireless-04 which discusses requirements. For my use-case, however, the ISP won't have a relationship with the server (content provider, if you will) because the server is an on-premise datacenter belonging to an enterprise or other business, rather than to a consumer-focused video streaming platform. This means the ISP won't accept draft-kaippallimalil-tsvwg-media-hdr-wireless metadata from any sender, because otherwise such metadata would be misused or abused, wreaking havoc with legitimate flows that should receive better service. At minimum, my use-case needs a mechanism to authorize honoring per-packet metadata from certain sending IP addresses, but once there is a way to signal those IP addresses, we could signal other metadata on a per-flow basis.  Some of this out-of-band host-to-network signaling would reduce the per-packet signaling proposed in draft-kaippallimalil-tsvwg-media-hdr-wireless; some would just assist with the per-packet signaling.

Hi Dan,

Very interesting! Can you please take a look at
draft-herbert-host2netsig, it would be great if we could derive a
first class solution in IETF for host to network signaling and all use
cases that are popping up.

Tom

>
> The gist of the idea is the receiver -- the user -- choses which incoming packets are treated differently by the network when a reactive policy event occurs (read: sudden congestion, packet loss to the receiver, etc.).
>
> This can provide immediate benefit to SRTP and RTP flows and media over QUIC (MoQ) as MoQ moves towards unreliable datagrams.  It also benefits other UDP-based protocols such as gaming.
>
> We wrote https://datatracker.ietf.org/doc/draft-rwbr-tsvwg-signaling-use-cases/ which explains the benefits of such a host to network signaling protocol and have been updating it this week at https://danwing.github.io/signaling-use-cases/draft-rwbr-tsvwg-signaling-use-cases.html (which will update the existing -01 on Monday).  Such a host-to-network signaling can also improve interoperability and provide version negotiation when there is a business relationship between the ISP and content provider, as proposed in draft-kaippallimalil-tsvwg-media-hdr-wireless-04.  As many signaling approaches are being considered, and for the sake of better interop, it would be beneficial to separate the definition of the metadata vs. channels used to share them.
>
> Mohamed Boucadair present draft-rwbr-tsvwg-signaling-use-cases at Tuesday's TSVWG meeting.
>
> -d
>