[tsvwg] host-to-network signaling requirements

Dan Wing <danwing@gmail.com> Sun, 17 March 2024 03:24 UTC

Return-Path: <danwing@gmail.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 7A4E5C14F706; Sat, 16 Mar 2024 20:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWkjF1Q98xu6; Sat, 16 Mar 2024 20:24:52 -0700 (PDT)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 88CC9C14F702; Sat, 16 Mar 2024 20:24:49 -0700 (PDT)
Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-6e6c8823519so3225836b3a.0; Sat, 16 Mar 2024 20:24:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710645888; x=1711250688; darn=ietf.org; h=to:cc:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=cOTB+JWPijRDjnhhSryczYfi2JHsJmg5om02egmFfZ4=; b=SsoUiCM5k41ZOVRw8JXKcsoMWPFvQRC1SSHQ+r/Z5DCudGLxErfnNwVbuvjTEbKkId x7FOlK/IhmWQel8eibZvx4iZjzJPt3ImxJWTnoj8+s9e1YDkweuVwXmPjn7Wn/HpXosK UztQygsD+THo4dbKE4Hfpnf4TH7KU+dtlV7ZMpgVo4rNmU3iHn+Us1zwsO8pQG1ZG0k3 9v548chts+aP7tIcLMy3h6KMJfk5+RM52MYRb2YH3+X9aYV9Hq9+XTqEPSN+ZujtT/3I SKRQM/L61guwmaNscwTXLZe6LEo3+pUZpTvy6qsfDkgVC6S4ZekO8BEGVW8Xd+rPrL1R RsjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710645888; x=1711250688; h=to:cc:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cOTB+JWPijRDjnhhSryczYfi2JHsJmg5om02egmFfZ4=; b=A2G6ylgfFtG7EbWtqGyreaZO6mPXlhueM1VL54gjOhgdVNC0bpbNIref67CoLfr9c8 sru0LYfQW5FXsWztJT3vtYe/9wh/7hxPCTvrXPML/TgYXkB8+MyMkoE91b3xC+OdsA7r Yt6t2efiKAxcMSlnIQUL0AdkRwfl9WCGTm3I8T+QOdMfnxjYqk10MxuylnB1F0dDcs1R BOWAbg1B8sryMYCR6HDDv+bm2CCiCk5aGRbdJTJq6CK17nu+d7YZL83HF5gqE9EhLzlA 8dmpjK1lG4lESxBhWGtm3vno8fVB6yYYS+cOFxfb9Sa2h1H83aN/4I9kRlZjawigRbsJ EHKg==
X-Forwarded-Encrypted: i=1; AJvYcCW1Q3Ut2UlkXKMBrfao5ptVsOL35IKwPPrl5c8CVYti0crnCKfwdfQfML6eb4JxkwK8NrxogYhRhCtoIDePMXJ+GBfE742+Ow0PvlH15TXtXW4dTiYTwIjzL/erVLI=
X-Gm-Message-State: AOJu0YyLc+B7XnquJA8cqNDxuc+0uzA8erOs1OelREmnSfUnsNJym8vR i8z8fAOXGYt4zs6wwdKH+XYqznzVhH8l4Au7GdKo/ec0iCglwt6LSHb1jiB0HakT+Q==
X-Google-Smtp-Source: AGHT+IGjO8kwmunSiDmLYM/yIaSPGAixrayTnekxM9Yk3bRXrMOr/qo0R/W7qVtvoTohLOcsFsmdUQ==
X-Received: by 2002:a05:6a20:d704:b0:1a3:600e:9d01 with SMTP id iz4-20020a056a20d70400b001a3600e9d01mr864396pzb.49.1710645888360; Sat, 16 Mar 2024 20:24:48 -0700 (PDT)
Received: from smtpclient.apple ([47.208.219.53]) by smtp.gmail.com with ESMTPSA id f17-20020a056a0022d100b006e6cc998be8sm5445580pfj.207.2024.03.16.20.24.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Mar 2024 20:24:47 -0700 (PDT)
From: Dan Wing <danwing@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1BF246C0-53FA-4401-AF59-E158DAF53FD9"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Message-Id: <9B0C7A76-5620-4630-B68E-44D4CCC9E1FD@gmail.com>
Date: Sat, 16 Mar 2024 20:24:47 -0700
Cc: draft-kaippallimalil-tsvwg-media-hdr-wireless@ietf.org, draft-rwbr-tsvwg-signaling-use-cases@ietf.org
To: tsvwg IETF list <tsvwg@ietf.org>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/cI8RenE2wY8qYvv8bVOk27n_fJY>
Subject: [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 03:24:56 -0000

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.

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