[AVT] Re: Comments on draft-ietf-avt-rtp-ac3-03.txt

[Magnus Westerlund <[e-mail]>]

Hi Brian,

Here is my response, see inline.

Link, Brian wrote:
> Hi Magnus,
> 
> I have looked through your comments. Thanks for the many that supply
> clarifying text or help the I-D conform to AVT expectations. For most of
> the comments, I'll incorporate your suggested text in the next version
> of the I-D. Here are a few of your comments where I have questions:
> 
> 
> 
>>1. Status of this memo: You need to update the boilerplate. 
>>Please use the text from RFC 3978 and 3979.
> 
> 
> I believe this was correct in the -03 version. I used the boilerplate I
> found in RFC 3978 and the file passed Idnits. If you see something
> specifically wrong, please let me know.

"This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667."

I reacted to this one. Because RFC 3667 is obsoleted. I think you can 
remove this text. Because I think it has to do with the statement in 
section 5.4 which you have included at the recommended place at the end 
of the draft.


> 
> 
> 
>>3. Section 3, timestamp: I think the enumeration of the 
>>sampling rate should using "or" instead of "and". The reason 
>>I comment on this is that a defined payload type and thus a 
>>single payload can't use different sampling frequencies . If 
>>different sampling frequencies needs to be supported on the 
>>same connection multiple payload types must be defined.
> 
> 
> I moved the sentence in question to section 2.1 where sampling rates and
> frame durations are discussed which I think is a better way to satisfy
> your concern.
> 

Okay, a clarification was all I needed.
> 
> 
>>10. Section 5.1, subtype name: Are there is a reason why this 
>>is registered in the vendor space, instead of in the general 
>>IETF tree? As we are having the specification of the payload 
>>format in IETF they are generally approved registered in the 
>>standards tree. I am especially concerned how we are going to 
>>handle the ownership/change controlling of this type.
> 
> 
> Can you explain more about the concern here? I don't think I have a
> strong opinion on this issue, but will need to check with some
> stakeholders. Part of my motivation for using the vendor tree is my
> understanding that that would reduce the time to RFC. (I'm still trying
> to beat a deadline to reference this eventual RFC in a DLNA
> specification.)
> 

The reason is that this payload format will become an IETF proposed 
standard. It will be under IETF change control. In this case it 
inappropriate to use Dolby's vendor tree. The expectancy is that this 
type will be used commonly. Thus I think moving it into the IETF tree by 
changing the type to "ac3" seems more appropriate. I use ac3 because the 
codec seems all through the document be called that.

In this case I think using a IETF tree will actually save time. 
Otherwise there will definitely be questions why a payload format going 
for proposed standard uses a vendor type.
> 
> 
>>12. Section 5.1: Ptime: Why isn't the normal definition in SDP (RFC
>>2327) referenced here?
>>
>>13. Section 5.1: Maxptime: Why isn't the definition in RFC 
>>3267 referenced? IF sdp-new is published before this 
>>document, one could reference that.
> 
> 
> Would it be acceptable to remove the text about ptime and maxptime from
> this payload format definition? I think those sentences got carried into
> the document from a template used by an earlier author. I don't see a
> need to alter the normal definitions, or even call them out (or
> duplicate them) in this document. (If this is acceptable, then I would
> leave out the sentence about ptime/maxptime from comment 17; and leave
> out references to RFC 2327 and RFC 3267 from comment 22.)
> 

I would be fine with simple having

ptime: see RFC 2327 [x]

maxptime: see RFC 3267 [y]

> 
> 
>>15. Section 5.1: Please remove the File extension, mac file 
>>type code, and OID registration. That is unless you intend to 
>>register a file format at the same time. However in that case 
>>you need to reference a file format definition and an 
>>analyzes if registration under the same name is appropriate 
>>or not must be performed.
> 
> 
> This change is fine. Can you point me at some guidelines for the
> analysis you mention? I would like to understand what I might best do
> (in the future) to register a file type.
> 
> 

No, not really. There is a debate about this and what will be allowed, 
etc. So lets take that discussion later, when we hopefully has resolved 
the issues.

> 
>>19. Section 6. Is there any any manipulation an attacker 
>>could perform to a audio frame that would result in that the 
>>codec crashes or uses significant more processing or memory 
>>to handle that frame. Examples of these would be to 
>>manipulate BSI, or dynamic range control. If the answer is 
>>yes, then this needs to be pointed out. This due to the 
>>Denial of Service threat that then exist.
> 
> 
> AC-3 decoders are required to identify and ignore malformed frames. I
> think the worst that can happen is that a decoder will mute and enter a
> state in which it searches for a sync word at the beginning of a new
> frame. I'll look into this a little more to confirm my understanding and
> add some wording to this effect.
> 

Okay, that sounds good

> 
> 
>>21. I am missing a congestion control section. This should 
>>indicate what operations I can perform to reduce the bit-rate 
>>and/or packet rate of the transmission.
> 
> 
> I wasn't aware this was required. Can you point me to some guidelines
> (and example text) so I'll understand what is needed here?
> 

Well, we try to get these in. The intention is to provide implementors 
with an indication of what they can do to reduced the bit-rate when 
faced with congestion control.

One example of this text is from BV draft:

    The general congestion control considerations for transporting RTP
    data apply to BV16 and BV32 audio over RTP as well, see RTP [1]
    and any applicable RTP profile like AVP [7]. BV16 and BV32 do not
    have any built-in mechanism for reducing the bandwidth. Packing
    more frames in each RTP payload can reduce the number of packets
    sent and hence the overhead from IP/UDP/RTP headers, at the
    expense of increased delay and reduced error robustness against
    packet losses.

This is appropriate text if you don't really have any possibilities to 
change the bit-rate. If you have possibilities to vary the bit-rate from 
the codec please indicate this. Also any other tricks besides 
packetization.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt