Subject: [AVT] AVT Draft Minutes

From: Tom Taylor <[email-masked]>
Date: Mon, 14 Apr 2008 16:40:47 -0400

The minutes still need one or two things cleaned up, but I'd better get them 
out. I'm still in the process of flying home after two weeks in China, with a 
very poor internet connection much of the time to complicate matters. Sorry to 
be so late again.

I'll submit the final minutes on Wednesday.

Tom Taylor

Minutes of the AVT Working Group, IETF 71

The AVT Working Group met twice at IETF 71, on Tuesday at 15:20-17:20 and on Thursday at 15:10-16:10. Roni Even <[email-masked]> and Tom Taylor <[email-masked]> chaired. Colin Perkins <[email-masked]> was unable to attend the meeting in person, but was listening in and monitoring the Jabber connection.

xx persons attended. Jim Failla and Stephan Wenger took notes.

FIRST SESSION: Tuesday 15:20-17:20

1. Agenda and Status
   =================

Roni Even presented the charts giving Working Group status. These are available at http://www3.ietf.org/proceedings/08mar/slides/avt-0.pdf. The charts began with an agenda review, the IPR NOTE WELL statement, and then went on to document status.

[Colin noted on Jabber that the Area Director has agreed that the Header Extension draft has solid consensus from the Working Group, so we will be re-issuing the request for publication after the authors issue a minor update.]

ATRACS passed WGLC with minor comments -- the authors will submit an update, people can review for a week, then we will send it to the IESG.

2.  Scalable Video Coding -- Thomas Schierl <[email-masked]> presenting.
    draft-ietf-avt-rtp-svc-08
    ==================================================
Charts are available at http://www.ietf.org/proceedings/08mar/slides/avt-6.pdf.

The initial charts presented recent changes, then went on to mailing list comments.
The next slide introduced the topic of decoding order recovery. There was a three hour meeting Tuesday morning, but the discussion did not reach a conclusion. The presenter expressed the desire to reach one now, at the meeting.

It was still unclear in the morning's discussion whether mode 0 could be supported by CL-DON. The presenter reviewed the CL-DON solution, and then the use of classical RTP mechanisms for order recovery. Then he showed possible solutions based on the morning's discussion. However, he noted that there is still no consensus.

Roni Even remarked at this point that we had had a design team working on this since last meeting. The design team is not a closed group -- it was announced on mailing list. The design team will continue until the open issues are resolved.

Thomas moved on to present the four open issues charts. On the fourth chart, he asked if we need a generic draft for the sprop-spatial-resolution parameter. Roni had no comment. Colin remarked that this would be something more than RFC 4566 a=quality:, presumably.

Roni expressed thanks to Mike Nilsson <[email-masked]>(absent) as well as all the other participants. 

Thomas Wiegand <[email-masked]> approached the microphone and gave his own summary of the proposals. He appealed for views from the floor, saying that there had been too much back-and-forth in the design team discussions. He noted that DVB and other SDOs have deadlines and would like to see this brought to a conclusion. Basically he asked for the ability to avoid using the technology they do not want.

Roni noted that other SDO requirements are a matter for the Area Director. We have to have rough consensus, but can consult with the AD on how to proceed.

Dave Oran <[email-masked]> introduced himself as an ex-AD and asked how long this debate has been going on. Stephan Wenger <[email-masked]> replied that at least a year ago he made a presentation on the order recovery problem. Stephan gave two choices then: put in some information -- a Nokia patented technology -- or go through a fairly complex and hard-to-understand specification process. The answer he got then was to go ahead with what he thought best. In short, we have been here before. Summing up, the two proposals are to add redundant information or not to do so. Nokia is not convinced the "classical" system would actually work under the constraints they face. Nokia already have a pile of patents -- this particular one is not important in the whole picture.

Dave Oran remarked at this point that if there is an even split in the Working Group, we have no process for dealing with it. He asked whether IPR disclosures have been filed. They have been, by both sides and by BT.

Colin noted offline the following IPR declarations:
 https://datatracker.ietf.org/ipr/736
 https://datatracker.ietf.org/ipr/852
 https://datatracker.ietf.org/ipr/832
 https://datatracker.ietf.org/ipr/910

Dave noted that the differences in terms of disclosures are something to be considered by the Working Group.

Thomas Wiegand proposed to tie the techniques to the modes -- classical for modes 0 and 1, CL-DON to mode 2. [Colin suggested that he should send text, then ask if there is consensus to accept it.] Stephan Wenger noted that packetization mode 2 is related to high-delay applications. One needs to buffer several pictures before doing meaningful decoding. It is also IPR-encumbered, but that is not to the point. The division between modes 0 and 1 and mode 2 is not the right dividing point. Timing requirements are definitely an issue. Nokia are not stalling the draft, as Thomas implied. They are simply not convinced it would work well without CL-DON.

Roni asked for the timeline requirements.

Thomas Wiegand said DVB need an RFC number for the SVC payload by December. It follows that we need a WGLC by summer. [Colin noted that WG last call can happen between meetings, of course.] Roni said that he had been hoping that based on work that day we could achieve a full consensus. We need to have a good description about what each of the methods means in terms of delay and other relevant charateristics.

Thomas Wiegand asked why RTP does not already provide a method to do this synchronization. Roni responded that it does, using the timestamp.

Thomas asked, then why add unnecessary IPR.

Stephan remarked that RTP allows correct reconstruction of transmission order. (Roni added that this is different from from playback order.) Stephan continued, that there is a difference between the basic RTP capability and the problem here, where we have to sequence parts of packets. Thomas Schierl intervened at that point to say that this problem arises with mode 2, not mode 1. There was some back-and forth discussion on the difficulty of the operation. Stephan summarized: he was trying to make the case that there is more complexity than the classical RTP mechanism was designed for. Roni agreed -- otherwise there would be no discussion. Ye-Kui Wang <[email-masked]> noted two differences from the classical problem. First, different sessions are sent to different decoders in the classical model. Also, we are trying in this case to restore the order set by the coding specification. 

Randell Jesup <[email-masked]> remarked at this point that startup time is an issue. Ye-Kui agreed, this is an important point. Roni remarked that Magnus Westerlund would be presenting on RTCP extensibility on Thursday. This would be a good time to discuss start-up time. [Magnus pointed out on Jabber that Joerg Ott would be doing the presentation on that topic.]

There was som discussion between Thomas Wiegand and Roni on what Nokia is saying. Thomas Wiegand asked again: if it is agreed that RTP method works, why not use it? [Colin remarked that RTP synchronisation says nothing about the decoding order of the media. This is the point Stephan Wenger seemed to be trying to make earlier.]

The Chairs cut off the line and discussion after Joerg Ott <[email-masked]>, who complained that our time is being wasted.

3. RFC 3984bis, Ye-Kui Wang <[email-masked]> presenting
   draft-wang-avt-rfc3984bis-00
   ======================================

Charts are available at http://www.ietf.org/proceedings/08mar/slides/avt-1.pdf.

Six charts described technical changes before the presentation moved on to open issues.
On open issue 6 (meaning of the capability parameters), Roni remarked that the point is that we want the semantics to be consistent. Ye-Kui pointed out the relevant text in the draft. Roni repeated his point. Stephan Wenger noted that this one had been discussed a while ago in a WG meeting -- it was marked as an issue over a year ago.

The presentation moved on to issue 7, level downgrading of parameter sets, which Randell jesup raised on the list. Randell explained the problem at the mike: trying to change the level without having the right parameter set is problematic. The peers may have to renegotiate. The sender could send every parameter set for every level he could be downgraded to -- doesn't seem good. Randell is really open to suggestions, but thinks it unlikely you can just modify parameter sets on the fly. 

Roni amplified that the problem is when you specify new level, and you want to use different parameters. The first point with H.264 is that the decoder should be able scale to anything.
In H.323 the parameter sets are sent inside the stream. This point has been raised before in connection with video switching. Stephan Wenger agreed that this discussion has occurred before, and he saw that no one had a better idea than the proposed solution.

Roni remarked that it should be clear that what you ask for is full information including the parameter set. Stephan pointed out that things are not the same in H.264 [ as in ??].
Roni summed up: basically we need a way to ask for a new parameter set. Stephan agreed, OK, we need to choose something. Roni and Stephan agreed to present options to the list.

Randell asked if we need to continue support for out-of band parameter sets? Do we need to support in-band parameter sets? If you are not downgrading the level, the problem is much simpler. He raised one other issue -- what do we allow to be downgraded? He is talking level 1B. Roni pointed out that H.241 says something on the subject. If not part of the hierarchy, 1B should be treated separately. [Tom Kristenmson remarked on Jabber that it may be an idea to include level 1B in this bis-draft.

Randell continued. Downgrade is a real issue. Regarding the other issues: external meanings (issue 1) should be out of scope. Roni agreed. Regarding issue 3, Randell pointed out that different payload types have different packetizations. You can't say a property of a payload stream is a property of a payload type.

Thomas Wiegand asked if we talking about a new profile here? Roni responded that we may have new SDP parameters. They should be approved in a separate draft. When we have an update to the main specification, we include the parameters in that document. 

Looking to the final chart: should this be a WG item? Several hands were in favour, none against. This will be a WG item (subject to confirmation on the list). We will merge it with the H.264 stuff.

4. RTP Payload Format for MVC Video, Ye-Kui Wang presenting
   draft-wang-avt-rtp-mvc-01
   ========================================================

Charts are available at http://www.ietf.org/proceedings/08mar/slides/avt-2.pdf.

The initial charts showed multiview application principles (as in last meeting). There was an update on the status of MVC standardization, a summary of the draft, and a list of changes since the initial draft. Ye-Kui asked if this could be a Working Group work item.

Thomas Wiegand asked if are we going to repeat all the SVC stuff here? [Colin noted on Jabber, repeated to the room, that it would be desirable to have a single mechanism for cross-layer synchronisation for all H.264 extensions, rather than a different one for each extension.] 

Stephan Wenger said he believes he asked for a sense of direction before. Should MVC be a delta on SVC, so we would end up having to read a whole cascade of documents?  Stephan expressed the belief that we agreed on a stand-alone document. We can work on the delta, then do any necessary copy-paste.

Roni said we don't have to worry for WG items.
..............
[The following text appears in my notes but it is unclear whether it records what happened at this point in the meeting. Can other people help out? -- Tom]

H.264 has provided parameter sets that describe sender rather than receiver preferences. Confusing interaction with usual SDP semantics. Jonathan has done work on this in MMUSIC.

AVT interest?

Roni: Second stream example: don't know SSRC in advance. Jonathan: SIP model -- re-INVITE in advance. May want to consider in-band solution.
Jonathan declined to include in draft.
Stephan: problem not critical for non-scalable H.264, though real. Useful, he is not opposed.
Confusion about effect -- updates everything but media types
Roni: shipping in-band solution
Stephan: Nokia's solution does not use in-band.
Roni: issue of repetition of parameter sets a major issue when switching sources.
Work on assumption that it is AVT draft eventually, keeping MMUSIC informed. Provide good motivation.
..............

5. Non compound RTCP, Ingemar Johansson <[email-masked]> presenting
   draft-ietf-avt-rtcp-non-compound-03
   ==================================================================================

Charts are at http://www.ietf.org/proceedings/08mar/slides/avt-4.pdf.

The authors felt a need for a new definition of non-compound packet, as stated in the charts. Jonathan Lennox <[email-masked]> asked a question for clarification.
Randell Jesup had no problem with either the previous or proposed definition.

The authors propose a Working Group Last Call after they have cleaned up the draft. This was agreed.

6. RTCPHR - Alan Clark <[email-masked]> presenting
   draft-ietf-avt-rtcphr-03
   ==========================================================

Charts are available at http://www.ietf.org/proceedings/08mar/slides/avt-5.pdf.

Alan noted that other SDOs are interested in HR.

Roni observed that Colin had sent a note about this draft to the list. It needs to address the organization of measurements (architecture). Roni suggested Alan correspond with Colin.
[Colin noted on Jabber: Alan said it himself - this is very application specific. We saw with RTCP XR that application specific metrics don't work well. Define a general metric, which can then be used for particular applications.]

Roni asked for other comments. There were none. He noted that Joerg Ott's draft on guidelines for extension of RTCP could be a guide. 

SECOND SESSION: Thursday 15:10-16:10

Roni Even summarized the status of the basic DTLS-SRTP specification. It will be sent to WGLC after WGLC of media security requirements has been completed in SIP.

1. DTLS-SRTP Key Transport - Dan Wing <[email-masked]> presenting
   draft-wing-avt-dtls-srtp-key-transport-01
   ===============================================================

Charts are available at http://www.ietf.org/proceedings/08mar/slides/avt-8.pdf.
The final chart on the voicemail storage and retrieval use case drew a comment from David Oran. He stated that the suggested configuration was fundamentally useless because the user cannot perform operations such as fast forward. SPEECHSC worked through this. The scenario is not realistic. [Randell Jesup remarked on Jabber that if message playback is done on the encrypted packets you have a problem because the sequence numbers/etc should change; you may not be able to simply replay encrypted packets in the more complex uses.  The VM server *could* decrypt and then re-encrypt to send to reader.]

Dan concluded by asking if there were WG interest in the work.

Roni Even said that he was personally interested in the MCU application, i.e., encrypting separate streams with the same key.

Eric Rescorla <[email-masked]> wondered whether this can be extended to DTLS and TLS. He and Dan got into a discussion with no clear result.

2. Why SRTP cannot be mandatory - Magnus Westerlund <[email-masked]>
   draft-perkins-avt-srtp-not-mandatory-00
   =================================================================================

Magnus presented on behalf of the author, Colin Perkins. Charts are available at http://www3.ietf.org/proceedings/08mar/slides/avt-9.pdf.

The first chart stated the issue: .......... The next chart pointed out that there is a wide variety of deployment situations/environments. The next chart explained why this draft was written. The final chart summed up status and open issues.
 
[Randell Jesup remarked on Jabber that at least pointers to the best practices, etc would be good.] Dan Wing commented that he liked the document, but it should add reference to practices that help enable security such as MMUSIC capability negotiations. Roni mentioned that some information on current practice is available from SIPIT. Dan continued: the document should not be saying "Don't use SRTP", but: "Here's how an RTP system can upgrade itself to SRTP". To him that is negotiation.

Roni and Magnus responded.

Dave Oran said that thesed are two different topics. How to do SRTP is a second document (pointing to Dan as the possible author). Dave continued: this document is right at the edge of saying too much, and he encourages the author not to go beyond that point. Sometimes, the problem of using SRTP is the environment, not the application.  One example is when RTP is being carried over IPsec. Magnus commented that this was a matter of definition of application vs. environment. Dave remarked that "application" is a loaded word.

Hannes Tschofenig <[email-masked]> sort of liked the document, but was concerned: how many "How to" books are going to be written? During IETF Last Call a lot of crazy comments fly around, and this document could help to improve that, but ... Roni and Magnus responded briefly. Magnus said the motivation was really to describe why SRTP is not needed sometimes. Stephan Wenger said that as he read it, this document is addressed to security people. The message is needed.

Roni Even asked who would be in favour of making this a Working Group document. 20 hands were raised in favour, with none opposed.

3. RTCP guidelines - Joerg Ott <[email-masked]>
   draft-ott-avt-rtcp-guidelines-00
   ==============================================

Charts are available at http://www3.ietf.org/proceedings/08mar/slides/avt-11.pdf.

The draft is a first pass at the topic. The first chart gave motivation, the next chart reviewed what RTCP was capable of. The next chart discussed the RTCP feedback loop.
[Randell Jesup remarked on Jabber, repeated to the room, that codec choices should be via negotiation or switching negotiated payload types. He couldn't see how RTCP is used for the purpose. Colin Perkins clarified that what was really meant was to negotiate as many codecs as possible, then switch between them freely based on RTCP feedback. Magnus pointed out in addition that in reality we are getting more codecs that actually vary rate and packetization within the same payload type.]

The presentation continued with security considerations, then posed a preliminary set of RTCP guidelines. Dave Oran suggested to add that RTCP should be carried in the same traffic class as RTP, and that the implications of this should be discussed. [Randell jesup remarked on Jabber,that with RTP/RTCP multiplexing it was even more likely they would be in the same traffic class, though not always guaranteed because intermediate nodes might re-mark them.] 

Roni Even asked how many had read the draft. About eight hands were raised. Roni noted that the draft should help to answer the questions that keep coming up on the list about timing and synchronization. [Randell Jesup remarked on Jabber, repeated to the room, that we should recommend that people not make a protocol/application depend on *ever* getting their RTCP packets through to the other end.] Stephan Wenger suggested that he would split the draft if he were author. One target those who really need to learn about RTP. The second topic is when and how appropriate it is to use RTCP. Joerg said the split might be appropriate after the document has grown a bit. Ingemar Johansson remarked that people should be warned against the use of RTCP for in-band signalling -- this topic is hopefully dead and buried. Roni agreed firmly that this was so, and we should not revive it. Joerg said as a last word that it would be good to have discussions on when it is useful to do extensions.

[Colin extended his thanks on Jabber to Magnus and Joerg for presenting in his stead.]

4. Using SEED Cipher Algorithm with SRTP - Seokung Yoon <[email-masked]> presenting
   draft-ietf-avt-seed-srtp-00
   ====================================================================================

Charts are available at http://www3.ietf.org/proceedings/08mar/slides/avt-10.pdf.

The presentation briefly reviewed the draft content and noted the changes since the initial Working Group draft.

Eric Rescorla asked if they had considered adding Galois counter mode as well. After a little discussion with the presenter Eric explained that the draft presented a specific choice of cryptographic mode with a certain setting, and with a specific MAC algorithm. There are other modes and settings you could use as well. The draft should explain why the specific choice was made.

Roni Even agreed. He called for WG feedback on draft, to get it ready for WGLC. There should be a new version before the next meeting.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt