Subject: Re: [rtcweb] WGLC for draft-ietf-rtcweb-video-04

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Mar 2015 14:09:21 +0100

On 2015-02-27 00:37, Sean Turner wrote:
> Dear WG,
> 
> This message initiates a WGLC (Working Group Last Call) for the "WebRTC Video Processing and Codec Requirements” draft:
> 
> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/
> 
> Please review the draft in detail.  This WGLC will end on 13 March, 2015.
> 

Hi,

I have reviewed the draft and have some few comments.

1. Section 5: Spelling error "WebRTC Brower"

2. Section 6:

   SDP allows for codec-independent indication of preferred video
   resolutions using the mechanism described in [RFC6236]. If a
   recipient of video indicates a receiving resolution, the sender
   SHOULD accommodate this resolution, as the receiver may not be
   capable of handling higher resolutions.

I would note that this document does not indicate an expectation of a
WebRTC Browser or non-browser to actually support a=imageattr. I would
have expected a clear formulation using RFC 2119 words on the need to
support this.

I also note that JSEP-09 lists a=imageattr as an open issue.

I think this unclarity needs to be improved. Either be explicit about
JSEP defining the need for implementing the attribute, or define in this
document, and JSEP's open issue will be resolved.

3. Section 7:

Implementers should consider
   whether the use of variable bit rate video codecs are appropriate for
   their application based on [RFC6562].

I don't quite understand the reference to RFC6562 here. That discusses
that audio codecs that have a variable rate based on the audio input can
leak information about what is said. This is primarily done through
voicing classifications on the frame basis that reveals the spoken
words. I fail to understand how that applies to video.

4. Section 10.1: This list to be a bit bloated. I find no reference to
the following reference, which also ID-nits find.

  == Unused Reference: 'RFC4175' is defined on line 345, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4421' is defined on line 348, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5104' is defined on line 352, but no explicit
     reference was found in the text

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Adam Roach <[email-masked]>
Date: Tue, 17 Mar 2015 11:55:13 -0500

> 1. Section 5: Spelling error "WebRTC Brower"

Thanks.

> document, and JSEP's open issue will be resolved.

Thanks for calling attention to this. I agree that the current treatment 
is a bit weak. I can also speak, from an implementation perspective, to 
the fact that we have run into circumstances (generally on lower-end 
mobile devices) where honoring imageattr is important. On the other 
hand, I do know that you can easily end up with encoding situations 
where the sending device has limited or no control over the resolution 
being encoded. I think MAY send and SHOULD honor is the right strength 
(and is in keeping with what the document currently says).

So I propose the following, which isn't a change in content as much as a 
change in clarity:

    SDP allows for codec-independent indication of preferred video
    resolutions
    using the mechanism described in {{RFC6236}}. WebRTC endpoints MAY
    send an
    "a=imageattr" attribute to indicate the maximum resolution they wish to
    receive. Senders SHOULD interpret and honor this attribute by
    limiting the
    encoded resolution to the indicated maximum size, as the receiver
    may not be
    capable of handling higher resolutions.

> words. I fail to understand how that applies to video.

There's an equivalent issue with video, in that variable bit rates can 
reveal the degree of motion in the frame. For something like a 
videoconference, this might not be a major issue. For something more 
like a surveillance camera trained on a typically static scene, this can 
allow passive attackers to deduce whether activity is taking place in 
the space covered by the camera.

I agree that 6562 isn't an ideal treatment for this topic, but neither 
do I think I should flesh this section out to be a complete "6562 for 
video."

So, I propose a brief summary of the issue: "Implementors should 
consider whether the use of variable bit rate video codecs are 
appropriate for their application, keeping in mind that the degree of 
inter-frame change (and, by inference, the amount of motion in the 
frame) may be deduced by an eavesdropper based on the video stream's bit 
rate."

>       reference was found in the text

Thanks. I've removed these.

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Mar 2015 10:12:49 +0100

Hi,

Please see inline comments on this.

>     capable of handling higher resolutions.

Two comments, do we actually want to mandate the implementation support
of a=imageattr?

I think the usage rules are fairly reasonable. I do wonder if we want to
be explicit about the SHOULD exception is really for cases where the
encoder can't be changed, for example due to lacking APIs to affect a
change on a webcam etc.

> frame) may be deduced by an eavesdropper based on the video stream's bit

Thanks, I hadn't considered that implication of the issue for video. I
think your proposal is appropriate. I note that hiding this behaviour
for the current video codecs is going to be very expensive in terms of
bits. The recommendation for mitigations that are in RFC6562 is not
really realistic to apply.

Cheers

Magnus Westerlund

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Mar 2015 09:09:05 -0400

> On Mar 18, 2015, at 5:12 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> 

We have to have some way for the application to limit the size of the sent video. This can be different for each codec but I would hope it would imageattr for new codecs going forward. I think we do have to mandate the browser pick a resolution that fits inside the envelope provides and I think that is can be done on even the low end mobile devices adam mentioned. Without this there is no way to know things will work.  If something sends 4k video to low end device, it probably can't decode it. If a device is transcoding between different video codecs, it may also need to constrain the resolution to fit inside a given box. It's not possible to build systems that are guarantee to work without a way to tell the browser a limit on the video size and be sure the sender will not exceed that limit. 

So I think the SHOULD needs to be a MUST.