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

[[e-mail]]

Hi John,

Glad to see that you are also for separating the metadata discussion from the signaling protocol itself.

FWIW, an attempt to define a set of $metadata for both host-to-network and network-to-host: https://datatracker.ietf.org/doc/draft-rwbr-sconepro-flow-metadata/.

Your input is more than welcome.

Cheers,
Med

De : Kaippallimalil John <[e-mail]>
Envoyé : dimanche 17 mars 2024 16:17
À : Dan Wing <[e-mail]>; tsvwg IETF list <[e-mail]>
Cc : [e-mail]; [e-mail]
Objet : RE: 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

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.