Subject: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 14 Feb 2012 18:34:35 +0000

WG,

This is to start the WGLC for the VP8 draft. 
https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/

Please send your comments and approvals to the payload list by March 1st.

Authors, you need to separate the references as informative vs. normative but please wait till the WGLC ends for a revision.

-acbegen

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 15 Feb 2012 22:32:47 +0000

Hi,

>From the draft:

"
   6.  Payload Format Parameters
      This payload format has no parameters.
"

I would suggest that, as the very minimum, some indication of
computational complexity of the bitstream ought to be signaled. My
understanding of VP8 is that it can support bitstream that differ in
decoding complexity by several orders of magnitude (different picture
sizes and frame rates).  The more complex bitstreams cannot practically be
decoded on lower end architectures (cell phones without HW acceleration).

AFAIK, the most common way to signal decoding complexity is in units of
macro blocks per second.  Ranges of MBS/sec are sometime classified into
"levels".

In the light of this discussion I would argue that the second to last
sentence of the security considerations section may be incorrect.  The
sentence reads 

"  This RTP payload format and its media decoder do not
   exhibit any significant non-uniformity in the receiver-side
   computational complexity for packet processing, and thus are unlikely
   to pose a denial-of-service threat due to the receipt of pathological
   Data.
" 

I would argue that VP8 carried inside the payload format as proposed does
exhibit such a non-uniformity.  I think I could trivially crash (or at
least "freeze") a system including a VP8 decoder by modifying just a few
packets of a complex packet stream, namely the packets containing the
frame size.  With previous standards, such an exploit was not easy, as it
was trivially possible to reject bitstreams of too high complexity, and
equally trivially possible to identify a non-compliant bitstream (in the
sense of non-conformannt to a negotiated maximum "level").

There were some initial discussions about some of these topics a while
back on the rtcweb list.  Harald mentioned at the time that the VP8
payload relies on non-payload specified signaling for picture size.  If
that's your choice, the payload format should explain so, and how picture
size ties into complexity signaling.

If parameters are going to be included, I would suggest to also address
the profile/version thing.  VP8 contains hooks to support different
versions and profiles (which, I believe, are not used at present).  While
I understand that it is possible to issue a new RFC for updated
versions/added profiles of the payload spec and negotiate based on payload
document number, it would IMO be cleaner and likely more future proof to
signal profile and version (or simply the three bits representing both).

Stephan