[AVT] IETF 74 AVT Minutes first cut

[Tom Taylor <[e-mail]>]

I'll improve the minutes for the second session before submitting, but in the 
meantime, please check everything for accuracy.

Tom Taylor


AVT  Minutes
============

AVT met for two sessions at IETF 74: Monday 1300-1500, and Thursday 1510-1610.
Roni Even and Tom Taylor chaired the sessions.

Monday 1300-1500
================

Dave Oran <[e-mail]> took notes, with some help from Joerg Ott 
<[e-mail]>. Jonathan Lennox <[e-mail]> acted as Jabber scribe. 
There were 75 attendees at this session.

Chair report (Roni Even)
========================
Slides at http://www.ietf.org/proceedings/09mar/slides/avt-0.pdf

- Slight change to agenda: moved security issues to Thursday, RTCP-XR moved to
today.

- NOTE WELL was presented.

- Chairs gave document status - see agenda/intro slides for individual document
details. Noted that SSM is blocking some key documents. Apparently a production 
problem -- using Word. In addition to drafts listed, noted that SVC and 3984bis 
are ready to go to the IESG.

- Received a liaison from ITU-T Q18 of WP1/16. Desire is to avoid tandem media
processing entities on a bearer path (e.g. echo cancellers). See chair slides
for discussion and details. WG is asked to give chairs input (via mailing list)
on how to respond.
Colin Perkins on Jabber: do we need a joint BoF to discuss requirements?

- Need charter update for RTCP extensions.

- There is an issue with codec references for media sub-type registration in the
standards tree when the codec itself is proprietary but the payload type is 
defined by an IETF document. Registry rules are unclear. Topic is on agenda for 
a meeting between the Chairs and ADs Thursday morning.

- RFC3016 mainly used by 3GPP, but some misalignments with 3GPP PSS service.
draft-schmidt-avt-rfc3016bis-01 provides updates. The authors want it adopted as 
a WG work item.

RTP Payload for IP-MR Speech codec
==================================
draft-ietf-avt-rtp-ipmr-02
Roni presented on behalf of the authors
Slides at http://www.ietf.org/proceedings/09mar/slides/avt-1.pdf

- on-the-fly adaptable wideband speech codec, VBR, etc.
- see slides for details of updates from previous version.
- Need review to ascertain whether it is ready for last call.

No one indicated that they had read the draft.

Rapid Synchronization of RTP flows
==================================
draft-perkins-avt-rapid-rtp-sync-03
Roni presented on behalf of the authors
Slides at http://www.ietf.org/proceedings/09mar/slides/avt-2.pdf

- general agreement to change name of the rapid multicast synch work to avoid
terminology confusion. This draft will keep the "rapid synch" terminology.

- current draft is a merge of draft-perkins... and draft-schierl...

- see slides for details on draft technical content and updates since -00.

- proposed solution to jitter problem is to use the NTP header extension for all
streams in the session

- trying to encourage DVB to use this spec instead of rolling their own for TM-AVC.

Chairs polled the room as to whether it should be a working group item. Hum
agreement it should be - will confirm on mailing list.

Ye-Kui Wang <[e-mail]> noted that "SSM" was spelled out in different 
ways. It should be "Source-specific multicast".

Rapid Synchronization with RTP Multicast Sessions
=================================================

(1) draft-versteeg-avt-rapid-synchronization-for-rtp-02
     ---------------------------------------------------
Presented by Bill Ver Steeg <[e-mail]>
Slides at http://www.ietf.org/proceedings/09mar/slides/avt-3.pdf

The drafts presented at IETF 73 were merged into this one. However, there is 
another draft dealing with this topic (see below). To avoid confusion with the 
Perkins-Schierl work item it is proposed to rename this draft to "Unicast-based 
Rapid Acquisition of Multicast RTP Sessions".

- See slides for background and enumeration of updates from last version.

- Current draft is a merge of -01 and draft=-levin-rtp-burst. They were similar
and not a big deal to combine

- Went to TLV encoding of the fields. The earlier dependence on MPEG-2 transport 
stream transport has been removed. Adding capability for vendor-specific fields.

Roni Even remarked that there was no text explaining how the TLVs are used and 
what is the behavior associated with them. Bill Ver Steeg said they would work 
to clarify the semantics. Dave Oran noted that in most cases these fields are 
used strictly for optimizations.  Roni argued that designers will not implement 
them if they see no gain from doing so. Authors will continue to consider the 
matter.

- issue around when and whether we can use extended RTP sequence numbers in the
control messages.

Breakout scheduled for Tuesday 9 am to discuss open issues.

Roni: once a it is a WG item we can think about fixing FMT items.

Xavier Marjou <[e-mail]>: was there thought as to 
whether everything should be in RTP header extensions rather than RTCP messages? 
He had NAT interference in mind. Dave Oran responded that most of the messaging 
fits with the AVPF control channel model, but it might be a good idea to 
piggyback RS->RR control information for burst rate changes. Zeev Vax 
<[e-mail]> added that you can derive burst rate from the received 
data, but the idea of using header extensions is worth considering.

Roni observed that we still need to iron out the details of the mechanism.
He would try to present the outcome of the breakout session on Thursday so we 
can get this to be a WG item as soon as possible.

(2) draft-peilin-avt-rtp-burst-01
     -----------------------------
Ye-Kui Wang <[e-mail]> presented on behalf of the authors.
Slides at http://www.ietf.org/proceedings/09mar/slides/avt-7.pdf.

- there may be Huawei IPR on the draft.

- General architecture adopts the draft-versteeg... approach

- Two new items beyond what is in the other draft
-- 1: allows burst rate to be controlled by RR, RS or both together.
-- 2: Method to terminate a burst based on initiation of a different burst
- See slides and draft for details.

Yunfei Zhang [??]: Requirements OK, but (1) not sure how receiver can know what 
bit rate to provide to the sender, and (2) are these mandatory
requirements of the solution?

- Roni: clarification of (1) how does the RR know the peak rate it can use?
Answer: receiver just tells what it may know. Followup: should IETF be
specifying optimal bitrates? YeKui: not looking to optimize. No need for IETF to 
specify -- situations differ. Roni: look at RFC 3550. Zeev: Burst typically 5-10 
seconds. Can't adapt faster than RTT allows. Need stable jitter and loss 
estimate. Takes longer than time available. Risk of increased overhead without 
adding value.

- Yunfei second question: is it implied that support of rapid channel change is 
mandatory? No - depends on provider, but question of making system work better. 
Dave Oran: bear in mind that this is an optimization of an optimization. Second 
point: if message fails, don't want to worsen subscriber experience.

RTCP-XR* Drafts
===============
Geoff Hunt <[e-mail]> presented.
Slides at http://www.ietf.org/proceedings/09mar/slides/avt-4.pdf.

- There is a large menagerie of these - see slides for a list. Split of drafts
due to a "re-architecting" of the XR drafts to separate the individual blocks to
be specific rather than packaged together in arbitrary sets.

- see slides for changes from prior versions.

A Cisco IPR claim affecting -xr-concsec was noted.

Al Morton: on PDV block draft, 2 points - (1) would good to reference an RFC on
PDV guidance (RFC5481), (2) Naming conventions in this draft no longer 
correspond to the terms we use in RFC3550 and elsewhere. He would be glad to 
help nail the names down, particularly before they get put into an IANA 
registry. There is now general convergence amongst SDOs.

Reviews requested.
Milestones still have to be firmed up. Cullen understands the logic of creating 
so many drafts, but suggested we discuss the prioritization of these drafts on 
the list.

RTP payload format for the CELT codec
=====================================
draft-valin-celt-rtp-profile-00
Presented by Greg Maxwell <[e-mail]>
Slides at http://www.ietf.org/proceedings/09mar/slides/avt-5.pdf

- Presented background of codec characteristics (see slides). On chart 4, Dave 
Oran what the Y-axis was for the bar chart on the right -- scores from ITU-T 
methodology.

- To solve early media problems - could burn a bunch of payload types
(combinatorics kill it) so need to choose some common combinations.

- Future work consideration is signaling configuration data, also need to freeze
the CELT bit-stream.

RTP Payload format for DV (IEC 61834) Video
===========================================
draft-ietf-avt-rfc3189bis-02
Roni provided a quick review.
Slides at http://www.ietf.org/proceedings/09mar/slides/avt-6.pdf.

- Minor changes from last draft (see slides)

Need opinions on whether this is ready for WGLC.

AVT Thursday Mar 26
===================
Roni and Tom chairing

Status
=============
Roni

Perkins synch
In favour of making WG item? No objections

Summary from burst breakout session (chart)
Revision then go to list to make WG item

DTLS-SRTP Key Transport (Dan)
=============================
Apologies, material to be uploaded after presentation.

Supports interworking with sdescriptions.

David McGrew states values to this independently of EKT -- interworking needed

?? can add description of interworking with MIKEY? Yes. Please indicate which 
variety of MIKEY is of interest.

Roni: verify that the call flows work correctly in interworking.


Encrypted key transport (EKT) David McGrew
==========================================

Master key conveyed to many participants.
Layer of indirection separating key management (who should have it?) from 
conferencing details.

Group controller sets up DTLS-SRTP key transport
EKT uses 1 to many RTP channel

Defined two years ago, premature. Essential for scaling to large groups -- 
avoids layer violations.
Currently ses sdescriptions

Eric Rescorla: what alternatives to EKT.
A couple of DTLS-SRTP extensions give almost as good results.

How would you know it is safe to send EKT messages? SDP.
Looks quite useful.

Roni: Do more discussion of tradeoffs before merging documents. Think about 
multi-unicast cast, which scales differently from multicast.

?? need reliability, RTP not reliable. David: can lose some packets. Dan: can 
send in either RTCP or RTP. In latter case, common fate. Sender can use more 
replication initially.

AES-192 and AES-256 David McGrew
================================

128 bit keys won't expire for decades, but might want to be ready for larger keys.
Possibilities: future advances in cryptanalysis, larger computers.
(Competition/compatibility ZRTP). SWEETPEA compliance.

Should we make AES-192 optional, make AES-256 the target.

Definitely add DTLS-SRTP binding.

Agreed, make standard

Jonathan: what about SHA-1? Offline discussion.

Cullen: make sure SecArea gets involved.

AES-GCM and AES-CCM autheticated encryption David McGrew
========================================================

AES-GCM

Encryption + authen -- no need for HMAC

Arguably efficient, esp. for short packets

AES-CCM more compact code.

Draft uses interface defined by RFC 5116

Eric: supports making WG doc. But why CCM? Roni: see if existing usage mandates use
Dan xx: might consider SIV instead of CCM.

SRTP Store and forward Blom
===========================

Draft refocussed on use cases and requirements.

Cullen only reader. Didn't understand it all yet.
Eric: wondered why all the layers. Response: other scenarios.

Continuing discussion. To the list.