From john.kaippallimalil@futurewei.com Sat Mar 16 23:17:38 2024 Return-Path: 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 EDB62C15109F; Sat, 16 Mar 2024 23:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 2rZFPIj6SVxS; Sat, 16 Mar 2024 23:17:34 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2094.outbound.protection.outlook.com [40.107.237.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DE9C14F696; Sat, 16 Mar 2024 23:17:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n818nRMeK++zjf2rXUKdDXgwp0YpDBij9HZJipVo+CoJFEpiOEPvd5VbOwi2jiGQ2OzZLQOlmm2FFoXQvLMdyROy9LLI7whnHoo6YAVBNMwzVDTwP6xEqM64z0r7t+6zLfm0/GF6Eh9KsTftTVCxgDzGjaIu3igQGtPXFIrg5IX7cSpQaxhngzE/3AhvwX0V0wFdyfpPb3M43qqvSJedOVB9lIMghNniIUWAYAtQQBAd54x/uLC+8y5T4qtcDyY/POh2Q4ApMeaa+6D+k+O5pWStg1UMrL6uayxxkgR/mbUuDwCjqmD3r+Hy5yVuM5t8lzoInzRz4FHqbEfUC4jjkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ukDm78+tgnrY0tZ+4K0zNrs/7p3TW/wqVklTt1XSa64=; b=MkG8Z/M1OHUEKJMsrqJY8UcPGfxJbo7rScBm+4CwjGlADCMsCyhXFBuF3HIs3ksc3kD2FEKmLs2+C80qH6RH3gmL9ABrSZF6NMPN7ZrtLvxii6s39RJn1pLUAwyJneyB3PtDWJjeSZTtC/GtnK/tv3qiUkSci89z6SelX0Reu9OlzpXkp4ow3cbiorv/duDY1ONHtqE+gRcRq/Sk+JdDwafKPkbdAKuJGjDIyomSmrrweyOEY60qbmEgLtFlbZhIwZXKi6F9AJuClcaHwAVK0iLgEvQP7Y3JhavmHe/U1pTHH7vYTEkhRz5M9IhodJg8l68KzewolkyV0ElIcvLcpw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ukDm78+tgnrY0tZ+4K0zNrs/7p3TW/wqVklTt1XSa64=; b=Ouy+oTBbOj4k6sX/dpq/DLkrvQc7KwE7EI4zXdTo4q3/e4oauxB8pC43BAPQY3e6fcW7bGVTGpFVqSsY50KwiKde3KcVTg3AIaoZ4gU6d+oxd/FzsHrF2DTtrZHJfVI2Rnbx5hbISUyf/FufdWii62QlPzpyBFj5wt1k9bsknNs= Received: from SN4PR13MB5311.namprd13.prod.outlook.com (2603:10b6:806:20a::7) by CO1PR13MB4856.namprd13.prod.outlook.com (2603:10b6:303:f1::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.21; Sun, 17 Mar 2024 06:17:30 +0000 Received: from SN4PR13MB5311.namprd13.prod.outlook.com ([fe80::27d3:2412:2388:bf6c]) by SN4PR13MB5311.namprd13.prod.outlook.com ([fe80::27d3:2412:2388:bf6c%4]) with mapi id 15.20.7386.023; Sun, 17 Mar 2024 06:17:29 +0000 From: Kaippallimalil John To: Dan Wing , tsvwg IETF list CC: "draft-kaippallimalil-tsvwg-media-hdr-wireless@ietf.org" , "draft-rwbr-tsvwg-signaling-use-cases@ietf.org" Thread-Topic: host-to-network signaling requirements Thread-Index: AQHaeBqy3TCzANEDT0mRosir3XKPorE7cWQw Date: Sun, 17 Mar 2024 06:17:29 +0000 Message-ID: References: <9B0C7A76-5620-4630-B68E-44D4CCC9E1FD@gmail.com> In-Reply-To: <9B0C7A76-5620-4630-B68E-44D4CCC9E1FD@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SN4PR13MB5311:EE_|CO1PR13MB4856:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PtrLra3JUUUgZmqLgEJoTHexjcQSRkL1In3wrnn0GrSskRNdt2j33EOugdpS62itOUXgK9gFpTbZiZ/rYtblATc0o36SixCGvN+m4hxfS4StYNdRUFdi0rv2YpL/E9Zyz42EX5nVC6PxdagpVqrA5miotiLAorhfrTSy9uv6LJ7WIxZKTGmn+6pfJ37SdssQffuxnZ6Bjt78YP8pWYFRmwlIM4roStm+BxSpE8kGZeUfv4N0WjRJ2AV9Bs0NvPEYxsKMMIw5yTrbxRqXH74XKmQDFc4Pcf5fm/KGTm8EpOfdm884lvXvAiRQVC6SIg84GJZYV2CBXYlSvpTAU3r+wd1thxqHdac4UcMd7fya9IbKEKJf4Jp89Hkqf29FDuZNcFKrhy3ELsYCQQQ7OSATcX2KnaE1rihpJHh5UaaiyafzDFbDff7YmX1CWgh12XT0V4DBBZ5DvghTiM3Er59SyQ4oXnqT217404qtIm+o/dxiXsMUVKmNpqnQ2DHCIQ0zALve0EduJWlfJFi+p9VuoldV5mLi3fsh2kUMgZ/AGctwJoD6fuAVCNlcBA23WO0O0R+LcuLQm4zDPf5CiyVZgO01UnqMyVfgFWYbH8j3eqE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN4PR13MB5311.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(1800799015)(376005)(366007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?xy/EyiBsq72ySvx6m6aTBhR23TBcZFb3ckBg2NwnkRAEatiU2r1/vkVzAIfJ?= =?us-ascii?Q?CEfd3ixJk1C7rpv408uWcmjNXFMQdqdHBpUkPlDEbSo4mv2h8EMMKYZPaWeA?= =?us-ascii?Q?CcEElI9eAfk1eUyavVngME+A+d/+pN+s1xwEXJFbEA3Xo0ufIU2/6sRx6Ikq?= =?us-ascii?Q?gA4+wlvXgyT/7S35TH2s+3cYm5VKCHKnWfm647xqDniQWu8+aAirGV969P6h?= =?us-ascii?Q?8aQOcCel606UNLTLUMIOErr6bhjwuvZSa1ZNYFQM+jHiMlk2ul8llNaoMWmv?= =?us-ascii?Q?tzIdDFvzy2G5wY/DWerJlkppvyZkDRCzx6ktVJr2e/svfu0FoFzohHarjSSK?= =?us-ascii?Q?0rLq6tWAA452RbjdaBsUKqOtQDz/OTFwpij0mmVvD0C77bKDtr42idX/2HXw?= =?us-ascii?Q?duy+Sh8r0/OvLkCBeZ0hbipODag3VqRxb8oFSWq9JN3PDl1/chkxHWJZ55qC?= =?us-ascii?Q?vvGTpaqOdOc29CIM8S9P2yagB2JO/ZlD4QnotxwQuAJjytJ7vR0zuNkyTJRJ?= =?us-ascii?Q?VsyilH2Q3DjCrxFU4h2w5qrR0761g3I+YHm8ZQOO1m73PJ+caV1fFfStR7CA?= =?us-ascii?Q?XF5AxoOpB+nddq4bs6Jox1s/ILxBgY5PfEtqcU/rXv3wTUN6GV06exu3UxgI?= =?us-ascii?Q?bXZVyKqSXpAP4Znx30jD2mfF9+yTLaCBAxOryETvIPtgPH+65I1oOn2ct/CD?= =?us-ascii?Q?HJSIOFaX76eQ/BA+eD2hlroM71tV1o5Gx27RopowevLtbglC1oSrtmeDCIhO?= =?us-ascii?Q?ADuQR9j/OdxVcwJSgdh5iukhdH9/f4y1OPLK3YOqu0JW/InowY3MF0vaN0wC?= =?us-ascii?Q?N+nulkP5aE5z43fOPEd8Y/Bel8BpF58PHuscRXUSMVLBjefJEnPcKabVshrC?= =?us-ascii?Q?76sbyQfX6p8KUKYeroU/TjNSukBLxqUe8/wuZDrgJb+wafgo+bNTY1aRdEtD?= =?us-ascii?Q?O4RUE/z826/y25DrScaPuNxj8ob4pX4HOwkByO4k01W7owkCkgPJAP0HutwW?= =?us-ascii?Q?x/v1MrTJFjmC1Xd4aAh9fuZv7Y+qms/NuHFy5Ki0q7d273omCEJ62SdMzcnP?= =?us-ascii?Q?ZADXLpDatVEBBWY8jTn1HhBvcz/17TuUhoS7BXxxh1Zpai08nUux4qrPbItL?= =?us-ascii?Q?Qx961qlj5w/iujrSACuGYvTGtBIa1uUB0V5FKegoSwtHKlFa6bJBqwHhV7Z+?= =?us-ascii?Q?vmvENN3oVF9O64iLrNpM/JTrXE4hjeizCX71kYrwM+dgpR/kaIq38OiIU95y?= =?us-ascii?Q?MvpKajTPwV2xQdI9Z4dKeLQTVeA6PkhckCNofdQnJVALjxMzMMedMW1xRhfs?= =?us-ascii?Q?N9DX12yWFzZX+BfNuvjv549X1nSZgTO858AJ3Z9jG1i8BEODfnxQMMjbmxT1?= =?us-ascii?Q?aB6UbdKMP0obswhm10fkdtZkA736ZEMa7eoHgmnDNPcmOehgenEoggW+Q9XZ?= =?us-ascii?Q?n9INsmZHzX3TA19IbhYYCZ5GyHJu/d1wXXb0ZUeGPvQzWPITa87InTIbvIAn?= =?us-ascii?Q?nulrVsWUOZ+MMbFoIPZa5vOOzsvfHGJ7Z2aBe8Qtk4fSfII/URbXjU40xKiL?= =?us-ascii?Q?inT0PpPsuc1IKi32GdrUohDiybb2PLYwOMZTVX18?= Content-Type: multipart/alternative; boundary="_000_SN4PR13MB531121EAAD98445E59845C53E82E2SN4PR13MB5311namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN4PR13MB5311.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21123082-41d8-49fc-9093-08dc4649ec9e X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2024 06:17:29.6107 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aotLta8IVY+JmnrM0r/5Z3Dz7ePGuC1XUAYNczjuMZkfAnmuRfhisAd9jOmHA8mLt5ZNsVZJuob2rVZyM35KOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR13MB4856 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2024 06:17:39 -0000 --_000_SN4PR13MB531121EAAD98445E59845C53E82E2SN4PR13MB5311namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree, these are different use cases and assumptions (reactive vs proactive= , per-packet-QoS vs. events, ...). Should keep the metadata in each of these drafts separate. Lets get agreement on the metadata in each of these first, and then think o= f the channels (transport ?) after that. BR, John From: Dan Wing Sent: Saturday, March 16, 2024 10:25 PM To: tsvwg IETF list Cc: draft-kaippallimalil-tsvwg-media-hdr-wireless@ietf.org; draft-rwbr-tsvw= g-signaling-use-cases@ietf.org Subject: host-to-network signaling requirements 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 rel= ationship with the server (content provider, if you will) because the serve= r 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 fr= om 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 me= tadata 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. S= ome of this out-of-band host-to-network signaling would reduce the per-pack= et signaling proposed in draft-kaippallimalil-tsvwg-media-hdr-wireless; som= e would just assist with the per-packet signaling. The gist of the idea is the receiver -- the user -- choses which incoming p= ackets 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 QUI= C (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-ca= ses/ which explains the benefits of such a host to network signaling protoc= ol and have been updating it this week at https://danwing.github.io/signali= ng-use-cases/draft-rwbr-tsvwg-signaling-use-cases.html (which will update t= he existing -01 on Monday). Such a host-to-network signaling can also impr= ove interoperability and provide version negotiation when there is a busine= ss relationship between the ISP and content provider, as proposed in draft-= kaippallimalil-tsvwg-media-hdr-wireless-04. As many signaling approaches a= re being considered, and for the sake of better interop, it would be benefi= cial 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 --_000_SN4PR13MB531121EAAD98445E59845C53E82E2SN4PR13MB5311namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree, these are different use cases and assumptions= (reactive vs proactive, per-packet-QoS vs. events, …).

 

Should keep the metadata in each of these drafts sep= arate.

Lets get agreement on the metadata in each of these = first, and then think of the channels (transport ?) after that.<= /p>

 

BR,

John

 

 

From: Dan Wing <danwing@gmail.com>
Sent: Saturday, March 16, 2024 10:25 PM
To: tsvwg IETF list <tsvwg@ietf.org>
Cc: draft-kaippallimalil-tsvwg-media-hdr-wireless@ietf.org; draft-rw= br-tsvwg-signaling-use-cases@ietf.org
Subject: host-to-network signaling requirements

 

I like the update to draft-kaippallimalil-tsvwg-medi= a-hdr-wireless-04 which discusses requirements. For my use-case, however, t= he 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, bec= ause otherwise such metadata would be misused or abused, wreaking havoc with legitimate flows that should rec= eive better service. At minimum, my use-case needs a mechanism to authorize= honoring per-packet metadata from certain sending IP addresses, but once t= here 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 s= ignaling proposed in draft-kaippallimalil-tsvwg-media-hdr-wireless; some wo= uld 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 f= lows and media over QUIC (MoQ) as MoQ moves towards unreliable datagrams. &= nbsp;It also benefits other UDP-based protocols such as gaming.<= /p>

 

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 an= d 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 sign= aling can also improve interoperability and provide version negotiation whe= n 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

 

--_000_SN4PR13MB531121EAAD98445E59845C53E82E2SN4PR13MB5311namp_--