[AVTCORE] IETF 81 meeting report

Roni Even <Even.roni@huawei.com> Sun, 14 August 2011 07:00 UTC

Return-Path: <Even.roni@huawei.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46A521F85F2 for <avt@ietfa.amsl.com>; Sun, 14 Aug 2011 00:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.979
X-Spam-Level:
X-Spam-Status: No, score=-105.979 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6fswUL2u04q for <avt@ietfa.amsl.com>; Sun, 14 Aug 2011 00:00:18 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB7D21F85BB for <avt@ietf.org>; Sun, 14 Aug 2011 00:00:17 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPW000OFOTLRX@szxga04-in.huawei.com> for avt@ietf.org; Sun, 14 Aug 2011 15:00:57 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPW005YCOTL84@szxga04-in.huawei.com> for avt@ietf.org; Sun, 14 Aug 2011 15:00:57 +0800 (CST)
Received: from windows8d787f9 (bzq-79-180-16-191.red.bezeqint.net [79.180.16.191]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LPW00BQQOTANG@szxml12-in.huawei.com> for avt@ietf.org; Sun, 14 Aug 2011 15:00:57 +0800 (CST)
Date: Sun, 14 Aug 2011 10:00:31 +0300
From: Roni Even <Even.roni@huawei.com>
To: 'AVT Core WG' <avt@ietf.org>
Message-id: <02b901cc5a4f$dfecb510$9fc61f30$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_zCCyB7APtd1tjw//+GRrPQ)"
Content-language: en-us
Thread-index: AcxaT9f/oXhnS9U0RZa3YY/Or3IigA==
Subject: [AVTCORE] IETF 81 meeting report
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Aug 2011 07:00:22 -0000

Hi,

This is the draft report for the AVTcore session in IETF81

Please review

Roni Even

AVTcore co-chair

 

 

Audio/Video Transport Core Maintenance (AVTCore) Working Group Minutes IETF
81

 

Chairs: Magnus Westerlund 

 Roni Even

 

Note Takers:    Brian Rosen

                        Bill VerSteeg

 

AVTCore Introduction and Status Update

 

These are the minutes for the AVTCore WG. The payload and XRblock WG did not
meet and the status was presented in AVText session.

The WG has published 7 RFCs, has 1 documents in AUTH48, and an additional 1
in the RFC-editors queue, and 1 documents with the AD or IESG. 

There are three WG documents that are not going to be discussed here today.
draft-ietf-avtcore-srtp-vbr-audio has just finished WG last call and is
ready for publication, but have received some minor comments that should be
addressed before publication request. draft-ietf-avt-srtp-ekt-02 and
draft-ietf-avt-srtp-aes-gcm-01 both needs review. 

 

Then the chairs reviewed the WG's milestones. We are already late on the RTP
monitoring architecture and the guidelines for VBR with SRTP. The later is
mostly done, but the monitoring architecture requires more work and needs to
be rescheduled.

 

The RTP Payload Format media types registry is not up to date. There was a
discussion what to do. Update it or discontinue it. The consensus is that
there is value on this registry and the payload chairs (Roni Even) will
update it. We will need to verify that it is updated with every new RTP
payload registered with IANA when registering in the general media type
registry.

 

Roni introduced a slide on  draft-singh-avtcore-mprtp-02 that did not get a
time slot since there was little email action on it.

 

 

 

 

Encryption of Header Extensions in SRTP

 

Jonathan Lennox presented draft-ietf-avtcore-srtp-encrypted-header-ext-00.
Action item for Jonathan to try to contact the GCM/AEAD authors in order to
support not only CTR.

Other issues were about having the references correct including the security
references.

 

RTCP Extension for Feedback Suppression Indication

Qin Wu presented draft-ietf-avtcore-feedback-supression-rtp-05. The open
comments were resolved. If there will be no more comments on the list, the
document will go to WGLC. 

 

 

 

Monitoring Architectures for RTP

Qin Wu Presented draft-ietf-avtcore-monarch-03.

The major open issue was about the identity block

 

Colin Perkins said that for correlating reports we have SSRC.  For
correlation of RTP with non RTP, we have source descriptions.  Fits better
in SDES. The chairs asked if there is a need for the identity block at all
and Colin see no need. There should be a use case to show a usage of
identity  block if want to keep it.

The draft will be revised accordingly and will see if ready for WGLC.

 

 

 

 

 

RTP Multiple Stream Sessions and Simulcast

Magnus presented draft-westerlund-avtcore-multistream-and-simulcast-00.

 

The first issue discussed was what type of simulcast is this and if the term
is correct, Magnus says that the draft defines it and he does not have a
better term. There was also a question if it is about simulcast or general
multistreams.

The next topic was about what is meant by multistreams and how it relates to
CLUE work. Magnus response was that it is about multiple RTP sessions,
typically one per video stream and one per video stream. The work addresses
only the RTP layer and not the CLUE framework multi-stream usage which may
need the support on the RTP layer.

Another topic in the draft is Bandwidth, talk about two issues, one of flow
control and the other is different bandwidth for send and receive, there
were comments that it affects also RTCP traffic. It looks like there is
interest in the topic but was considered during the discussion to be a
separate topic from the simulcast multiple streams.

On the SSDP signaling Useful for Retransmission, redundancy and simulcast
Jonathan Lennox - we have solutions for retransmission, but they are awful.
This would make it much better.

The general feeling was that the draft offers solution but the problem it
wants to address is broad and not clear, would like to start with
architecture description and requirements. Hadriel claimed that it may
require a new WG on the topic.

There was a strong HUM to start working on architecture of simulcast,
multistream. The BW is a separate issue.

 

 

 

 

Delayed Duplication Attribute and Duplication Grouping in SDP

 

Two MMUSIC drafts were presented by Ali Begen since there is a relation to
AVTcore.

 

draft-begen-mmusic-temporal-interleaving-02 - This draft propose to
duplicate the main stream with one or more copies which are delayed. The
major issue raised was that if the loss is due to congestion this will make
it worse.

Some of the comments that were made:

 

Colin - failures may be a valid reason to do this, not congestion

Colin - exact dupes need to be sent in a separate session. Payload type
SHOULD be the same, but nothing breaks if you use a different payload type

Colin - about signaling, if you have a box that does not understand the SDP,
it will try to render both streams

Jonathan Lennox - what is the cause of these outages if it is not
congestion? Something between every packet and partial stream?

Ali Begen- routing errors cause data loss - particularly in core networks.

Other comments were that this looks like a FEC with worst algorithm. It make
sense if CPU resources are more expensive then network bandwidth.

Ted Hardie- need an applicability statement, place where this is a bad idea
- subject to a "stupidity attack" based on a bug or bad configuration

Chairs: This is an MMUSIC draft but the issues raised are relevant to
AVTcore so need to be addressed.

 

 

 

 

 

 

draft-begen-mmusic-redundancy-grouping-01

 

This is the SDP for grouping, was discussed in MMUSIC

Comments:

Colin - these streams presumably send RTCP back - does this work with
encryption?

Colin - You do not need a new XR report. The middlebox is just a mixer.

Ali - there may be additional elements to report.

Colin - the existing mixer semantics would probably work.

Magnus  - there are grouping issues, and we need to figure out which group
addresses it, currently MMUSIC.

 

 

 

Retransmission for SSM sessions

Ali Begen presented draft-vancaenegem-avtcore-retransmission-for-ssm-00.

There was no discussion. An open issue if this is AVTCore or AVText since it
address a specific use case.

 

RTP Session Multiplexing

 

 

 

Magnus introduced the topic it came from discussion in RTCWEB. RTP requires
a lower transport layer to separate RTP sessions on the other hand desire to
use one UDP port to address NAT/FW and IPv4 issues. 

There was a breakout session and the proposal is to have a short term
solution that will use one RTP session for audio and video for RTCWEB. This
usage will be signaled. The RTCweb solution will also allow fallback to
separate sessions for audio and video to be used for example for FEC, and
backward interoperability. 

There will be work also on a long term solution which provides a generic
muxing solution of multiple RTP sessions by adding an explicit RTP session
identifier somewhere.

Some of the comments:

Bill VerSteeg - need to consider the multicast case in AVT, as the RTCWEB
folks are primarily considering unicast 

Adam Roach - questioning the number of media streams allowed - multiplexing
could have an arbitrary number of flows. 

Magnus - talking about one session for all streams.

Harald - applications do not have to use multiplexed sessions, but they may

Colin - FEC cases may not always work with session multiplexing, but
Audio/Video/Text will work

There was a question if short term is different than long term. This is not
defined yet.

The chairs took a HUM if there is an interest in working on this issue in
AVTcore and there was a strong consensus.

Bill VerSteeg and Colin Perkins volunteered to work on requirements for long
term solution.