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

["Shihang(Vincent)" <[e-mail]>]

Agree. What metadata is needed is orthogonal to how these metadata is signaled. The latter depends on deployment/protocol used etc. We should develop a common requirement for metadata signaling such as protecting privacy, authenticated etc.

Thanks,
Hang

From: tsvwg <[e-mail]> On Behalf Of Kaippallimalil John
Sent: 2024年3月17日 16:17
To: Dan Wing <[e-mail]>; tsvwg IETF list <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [tsvwg] host-to-network signaling requirements

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 of the channels (transport ?) after that.

BR,
John


From: Dan Wing <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, March 16, 2024 10:25 PM
To: tsvwg IETF list <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 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