Re: [AVTCORE] WG Last Call: "Frame Marking RTP Header Extension"

[Stephan Wenger <[e-mail]>]

Inline in blue.
S.

From: Bernard Aboba <[e-mail]>
Date: Sunday, November 22, 2020 at 06:40
To: Stephan Wenger <[e-mail]>
Cc: IETF AVTCore WG <[e-mail]>
Subject: Re: [AVTCORE] WG Last Call: "Frame Marking RTP Header Extension"

Stephan -

Thank you for raising the question of implementation experience. I will start a separate thread to attempt to collect this, since it does not appear to have been discussed on this list.

Can you expand upon your remarks (in a separate thread) with respect to SRTP and Sframe? AFAICT Sframe does not obsolete SRTP, nor does it lessen the need for a frame forwarding RTP header extension.

Yes I can.  Sorry for the word count.

The problem both frame marking and sframe try to solve seems to provide a MANE or SFU sufficient information to do its job—selective forwarding but also hop-by-hop repair and such—without being themselves trusted.  Both frame marking and sframe attempt (or appear to attempt in the context of sframe—the design is too new to be sure) to abstract from the syntax of the various codecs.  This is sensible from an SFU maker’s viewpoint—they want to reuse the same logic independently from the codec in use.  But it’s hard to do.  As a historical anecdote, we video coding people in the ITU and MPEG tried the same since ~2000 (starting with H.264v1), and when we finished any of the versions we were quite convinced that the NAL unit header plus the context info from the capability exchange (including things like parameter sets and later the SSEI and such) would be sufficient for informing an SFU.  They are not.  We got it wrong every  time, despite many, many more eyes looking into this over in JVET and its predecessors than avtcore or sframe have typically available today.  H.264/SVC/H.265/SHVC SFUs in practice all need to look into the slice header, and we heard during the session from Justin that the VP9/AV1(?) based SFU designs do the same.

As of today and to the best of my knowledge, the idea of untrusted SFUs or MANEs has not seen deployment, despite real-world customer demand for it.  All “modern” (zoom-like) systems that are not webrtc and where I had a chance to have at least a brief glimpse under the hood, at the time I had that glimpse under the hood, seem to rely on transport-level, hop-to-hop encryption and go about their business of analyzing the RTP packets, and their payload as necessary, after they decrypted the RTP packet flow.  Many systems take ideas from RTP but do not implement the whole spec, especially wrt. multicast/CSRC support, SDP, and congestion control.  Interop in this field seems to be a non-goal, and walled gardens rule.  I don’t believe any of the “modern” non-webrtc system use SRTP in anything close to a standard compliant way, though I would love to be corrected on that.

The implementation reality of webrtc seems to be that SRTP is used in a more or less standards compliant fashion.  Others here are certainly more competent in discussing this than I am.  It is also my understanding (from places like Wainhouse—paywalled and not cheap, so no reference) that non-webrtc video conferencing minutes are still at least an order of magnitude higher than webex minutes—some say two orders of magnitude recently—though webex is slowly catching up.  Again, I would love to be corrected here.

Now, with respect to sframe.  My impression from the sessions at this IETF and a brief reading of the omara-sframe-01 is such that sframe uses parts of SRTP technology, specifically the packet header.  However, the underlying transport stack is not only IP/UDP but typically something else that, as a minimum, allows authentication (DTLS is mentioned, but I guess it is only an example, and the real target may be some form of web-transport, QUIC, or whatever, with or without DTLS).  In any case, this is not vanilla SRTP as I think it was designed back in the days, it’s just a re-use of a header format, perhaps for convenience.  Sframe would work just as well if it were using a newly designed header format.


On Nov 21, 2020, at 19:45, Stephan Wenger <[e-mail]> wrote:
All:
This is not a hard objection, but I want to inquire if there is anyone out there who continues to think that frame marking as originally proposed is still a good idea and will see implementations.  The main reason I want to know is that accepting frame marking as an RFC would imply, per previous WG agreement, that future video codec payload formats include a (mandatory?) section on how to map the codepoints in the frame marking draft to the codec in question.  That’s non-trivial cost and effort, and chances are that effort will grow over time as codecs develop beyond what was mainstream in 2016.
What triggered my thinking about dumping frame marking are a) webrtc’s removal of frame marking as a required to implement technology, b) the decreasing relevance, as I perceive it, of SRTP for which frame marking is predominantly designed, and c) the myriad of new ideas in the IETF that skin the secure-SFU cat in different ways (sframe among them, but not the only one).
Stephan


From: avt <[e-mail]> on behalf of Bernard Aboba <[e-mail]>
Date: Saturday, November 21, 2020 at 13:08
To: IETF AVTCore WG <[e-mail]>
Subject: [AVTCORE] WG Last Call: "Frame Marking RTP Header Extension"

This is an announcement of WG last call on "Frame Marking RTP Header Extension"

The document is available for inspection here:
https://tools.ietf.org/html/draft-ietf-avtext-framemarking

WG Last Call will end on December 6, 2020.

In response, please state one of the following:

* I support advancing "Frame Marking RTP Header Extension" to Proposed Standard
* I object to advancing "Frame Marking RTP Header Extension" to Proposed Standard, due to Issues described below <Issue description or link>.

Bernard Aboba
For the Chairs
_______________________________________________
Audio/Video Transport Core Maintenance
[e-mail]
https://www.ietf.org/mailman/listinfo/avt