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

[Dan Wing <[e-mail]>]

On Mar 17, 2024, at 7:56 AM, Tom Herbert <[e-mail]> wrote:
> On Sat, Mar 16, 2024 at 8:25 PM Dan Wing <[e-mail]> 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,

Yes, I like draft-herbert-host2netsig and its evaluation of state-of-the-standards (so to speak).

We are proposing something different, which solves a problem we see:  namely, the client needs to be involved in metadata signaling of the packets sent *towards* the client.  The existing mechanisms summarized in draft-herbert-host2netsig are all about the sender (server) declaring metadata (in UDP options, in IPv6 options, flow-id, RSVP Path, DSCP, etc.) which are ignored by networks (most often) or honored by networks (if there is a pre-arrangement to honor such metadata signals from that sender).  What we are proposing is the client is involved and the client authorizes the network to honor incoming metadata signals on packets going towards the client.

Such client-to-network authorization allows building an egalitarian solution for users — so for any sender IP the client can indicate it wants network assistance with that flow.  Without such client-involved signaling we are at the mercy of ISPs configuring their equipment to honor metadata from certain sending IP addresses.

-d