[AVT] Draft minutes from Dallas

Enclosed are draft minutes from the AVT working group session in  
Dallas. Comments and corrections to the chairs please.

Colin

Audio/Video Transport (AVT) Working Group Minutes
=================================================

Reported by Magnus Westerlund and Colin Perkins

    The AVT working group met once at the 65th IETF Meeting (March 2006,
    Dallas). Subjects under discussion included management tools for RTP
    (MIBs and RTCP XR extensions), new payload formats, codec control,
    RTCP extensions for SSM sessions with unicast feedback, and security
    parameter negotiation for SRTP. The meeting was chaired by Colin  
Perkins
    and Magnus Westerlund, and 132 people signed the blue sheets.

Introduction and Status and Charter Update

    The WG has had 11 RFCs published since last meeting, has eight  
drafts in
    the RFC-editor queue, and a further six in various states of AD  
and IESG
    review. Colin Perkins expressed the WGs thanks to the RFC-editor,  
Allison
    Mankin and the rest of the IESG for their hard work. The chairs  
briefly
    reviewed the status of the other working group drafts.

    Colin Perkins highlighted draft-westerlund-avt-rtp-howto-00.txt  
which
    provides guidelines and advice for authors of new RTP payload  
formats,
    and solicited comments from the working group. There was strong  
support
    for such work, and since this is already a charter item, the  
document
    was accepted as a working group draft.

    The chairs noted that the charter needs updating to include the  
RTCP XR
    extensions and codec control messages drafts. Discussions with  
the area
    director on a new charter to include these items are ongoing.

    Colin Perkins announced that Magnus Westerlund will step down as AVT
    co-chair within a few weeks and thanked him for his contributions. A
    replacement has not yet been decided, although several candidates  
are
    under consideration.

    In addition to the new co-chair(s), formation of an RTP payload  
format
    directorate is being considered. The directorate would help  
ensure that
    all payload formats get proper review at least at acceptance as  
WG item
    and in WG last call. Volunteers were solicited.

RTP MIB and RTCP XR MIB

    draft-ietf-avt-mib-rtp-bis-00.txt
    draft-ietf-avt-rtcp-xr-mib-04.txt

    Alan Clark outlined the structure of the revised MIBs, and  
highlighted
    changes in the latest versions of these drafts. Discussion  
centred on
    two issues: session identification and inclusion of signalling  
data in
    the MIB.

    On session identification, Colin Perkins noted that the SSRC  
cannot be
    used as a unique session or participant identifier, since it may  
change
    due to SSRC collisions, and because multiple participants might  
use the
    same SSRC at different times within a single session. Magnus  
Westerlund
    then noted that it is important for that MIB to cover the full  
range of
    scenarios supported by RTP, and explained that an RTP session cannot
    be identified by a single address, since the session may span  
several
    transport connections provided they share a single shared SSRC  
space.
    Roni Even agreed, and noted that, to some extent, there is a higher
    level issue, since signalling knowledge is required to understand  
which
    transport connections that comprise an RTP session.

    On the inclusion of signalling data in the MIB, Colin Perkins  
noted that
    the draft RTP MIB includes several fields that relate to  
signalling, not
    RTP. Colin suggested the RTP MIB is not the appropriate place to  
include
    signalling data, and Magnus Westerlund suggested the SIP MIB as an
    alternative. Alan disagreed with the use of the SIP MIB, since  
not all
    applications use SIP and the main is to provide a general RTP  
monitoring
    framework; Roni Even pointed to H.323 systems as an example that  
could
    use the RTP MIB but don't use SIP. Mark Baugher and Magnus  
Westerlund
    commented that the right approach may be to correlate in the  
management
    application somehow, perhaps by including an opaque tag in both  
RTCP and
    in the signalling, which could be used to correlate the RTP MIB  
and the
    signalling related MIBs.

    It was clear that fundamental issues remain to be resolved before  
the
    new MIB design can be considered stable.

RTCP XR Video Metrics

    draft-clark-avt-rtcpxr-video-01.txt

    Alan Clark presented the RTCP XR video metrics draft, outlining the
    metrics conveyed and the scenarios where it is expected to be  
useful.
    As with the RTP MIB, discussion centred on duplication of signalling
    information within RTCP (in the configuration block of the RTCP XR
    video metrics).

    Magnus Westerlund asked if a video quality probe can operate without
    access to the signalling? Alan Clark responded that it is quite  
easy to
    detect RTP streams automatically, inferring the type of payload  
present.
    Stephan Wenger commented that heuristics for video codecs will  
get less
    reliable as the video codecs get more complex, and noted that it  
seems
    unwise to use them as the basis for a standard. Steve Casner  
commented
    that encryption will also make it difficult to analyse streams  
unless
    trusted with access to keying material transported with the  
signalling.
    Alan Clark and Rajesh Kumar responded that the goal is to address
    reasonable scenarios where system monitoring and management are  
needed
    today and in the near future, and the combination of heuristics  
and the
    inclusion of a limited subset of signalling information within  
RTCP XR
    would enable this without significant overheads.

    Colin Perkins acknowledged the need for management, but disagreed  
with
    the need to build a short term solution that duplicates the  
signalling
    data in the RTCP XR reports. Colin explained that a general  
purpose way
    of correlating the signalling information with the media can be  
used to
    build a system that will work in the long term, not only in the  
short
    term. There is an architectural model here that intentionally  
separates
    the media and the signalling: please do not break that model for  
some
    short term benefits.

    Rajesh Kumar and Alan Clark expressed some concerns that  
correlation of
    the full signalling and media data would be expensive and  
difficult to
    achieve in real-time, compared to including the signalling  
information
    within RTCP XR.

    There was no conclusion to the debate within the session, but it is
    clear that there is significant push-back against the current  
approach
    of duplicating signalling information within RTCP XR metrics.

RTCP XR High Resolution VoIP Metrics Report Blocks

    draft-clark-avt-rtcphr-01.txt

    Alan Clark discussed the High Resolution VoIP metrics RTCP XR  
reports,
    providing more extensive and accurate monitoring of voice  
sessions. It
    was noted that these metric include signalling information within  
the
    report blocks, and so have the same issues as discussed for the  
video
    metrics.

    Discussion was limited to a queries on the usefulness of more than 8
    bits of resolution for MOS scores, and various terminology  
questions.

SVC Payload Format

    draft-wenger-avt-rtp-svc-01.txt

    Stephan Wenger presented the updates on the draft. The current  
draft has
    an issue with the signalling, which is under-specified. There has  
been
    some mailing list discussion on doing an generic (not codec  
specific)
    solution for scalable codecs.

    The second issue is that the SVC codec needs to decode data in the
    correct order over the different layers. The proposal is to use  
decoding
    order number that uses a common numbers over the different layers  
and
    thus RTP session. Nokia claims IPR on the decoding order numbers,  
see
    statement. The alternative would be a very complex description on  
how to
    determine the order.

Codec Control Messages using AVPF

    draft-wenger-avt-avpf-ccm-03.txt

    Stephan Wenger thanked the group for their comments on version 02  
and
    presented the updated draft. Colin Perkins commented that it has  
been
    suggested to break out the topology section into a separate  
document.
    Stephan responded that he would be happy to, as long as he got  
some help
    from someone that really understands it. Colin indicated his  
willingness
    to review such a document.

    Colin Perkins also noted that the CCM messages have the ability  
to turn
    RTP into general request/response protocol and expressed concern  
on the
    potential for abuse this raised. Stephan noted the concern, but  
pointed
    to the section of the draft explaining when it is acceptable to  
use the
    notifications as a response to requests.  Flemming Andreasen  
commented
    that this problem already exists, and is not significantly  
worsened by
    this proposal.

RTCP feedback messages for packet delay adjustments

    draft-hdesineni-avt-avpf-ccm-pd-extn-00.txt

    AC Mahendran presented the initial proposal for a packet delay CCM
    message, to control packet delivery in time varying wireless links.
    This allows receivers to provide direct feedback to the sender to
    control packet sending delay.

    Steve Casner, Joerg Ott and Roni Even noted that sender based delay
    adaptation is not useful in many scenarios, and that rate  
adaptation is
    typically required (i.e. the aim is not to reduce buffering delay  
at the
    sender, but rather queuing delay in the network, which can only  
be done
    by reducing the sending rate). They noted that it is not clear  
that the
    existing measurement reports can't be used to control rate  
adaptation,
    and that it's not clear that this mechanism would see any more  
use for
    adaptation than existing metrics.  AC responded that the delay  
was the
    best measurement they had found, and that the existing metrics don't
    handle handle wireless very well, so he considers this appropriate.
    Magnus Westerlund disagreed, commented that what we are  
discussing is
    congestion control. In that space we need to consider how successful
    earlier delay based proposals, such as TCP Vegas, have been. In  
addition
    we should consider if we should develop to ad-hoc congestion  
control for
    RTP, rather than developing general purpose solutions at the  
transport
    layer.

    Steve Casner commented that you don't really care about the delay  
when
    what you are changing is the rate. If the rate quickly varies, then
    service will not be appealing due to frequently occurring rate  
changes.
    Instead it is likely that the service will use the lowest  
available rate
    and the adaptation will not need to happen. The quality if you adapt
    will be worse than if you run at the lowest rate constantly  
available.

    Joerg Ott expressed concern that the use of AVPF events will not  
work
    well with this system: the feedback will be queued in the network  
and
    this delay will causing slow response and likely oscillation. He  
also
    noted that AVPF is not intended for frequent reporting and  
congestion
    control, but instead to report occasional media events. AC responded
    that not using the feedback to prevent congestion would cause even
    greater congestion. This is true, but Joerg's point is that better
    congestion control can be achieved using a protocol designed to  
provide
    congestion feedback, rather than trying to retrofit it onto AVPF.

    Colin Perkins summarised that the proposal got pretty strong push- 
back.
    Cullen Jennings commented that if this is to be chartered there  
would
    need to be people confident in stating -- with strong evidence to  
show
    as justification -- that packet delay would work even if we  
normally use
    packet loss to measure congestion.

RTCP Extensions for SSM Sessions with Unicast Feedback

    draft-ietf-avt-rtcpssm-11.txt

    Joerg Ott presented the changes in the latest version. The major  
change
    is the logical split of the distribution source and the feedback  
target.
    The changes have result in the need of fixing nits and  
clarifications.
    There will be a new version shortly which is expected to be ready  
for
    working group last call.

ZRTP

    draft-zimmermann-avt-zrtp-00.txt

    Philip Zimmermann presented the goals, design, and future steps  
of ZRTP.
    One of the main points is that this way one can avoid having the
    signalling chain know or even care about the use of security and the
    key-exchange.

    Steve Casner commented that this is hacking signalling into the  
media
    transport to avoid perceived problem with the current signalling  
layer.
    Also if one would do this, it is really questionable if using the
    header-extension is the right way. For example using a different  
payload
    type would be a better choice. Philip responded that using a payload
    type would be fine, there is no special attachment to using the  
header
    extension. However the key-exchange is not hacking signalling  
into the
    media: the key-exchange should not be considered signalling, and is
    something that has been done before, for example in the PGP  
phones over
    PSTN. In those cases it not a signalling problem. Steve responded  
that
    this distinction is not particular clear when everything goes  
over the
    same pipe, but that we have a clear separation of media and  
signalling
    in RTP which this violates.

    Alan Johnston commented that so far it has shown to be difficult  
to do
    the key-exchange in the signalling due to forking, early media  
issues.
    People have tried several other solutions without getting them to  
work,
    therefore it seems that putting at least some element into the media
    path is the solution is the solution. Colin Perkins commented  
that an
    on-media-path solution doesn't necessarily have to involve RTP:  
another
    approach is to setup a signalling channel in parallel to the  
media, and
    use that for key exchange. This might be a cleaner approach,  
avoiding
    the confusion of media and signalling, and allowing a single control
    channel to be used for multiple media.

    Roni Even noted that the Diffie-Hellman exchange is time consuming
    and processor intensive, and asked if the authors have any  
proposals to
    reduce the burden when one has multiple streams? Philip was  
surprised to
    find that one actually has different RTP sessions for audio and  
video.
    This problem they are going to look into.  Several others noted  
concern
    over the computational complexity of Diffie-Hellman on low-end  
devices.

    Lakshminath Dondeti reminded the group that MIKEY can be both  
efficient
    and capable of handling peer-to-peer communication over UDP  
(independent
    of the SIP signalling channel). He urged the group not to forget  
this in
    a rush to develop new protocols. Further comparison between  
protocols
    was deferred to the RAI area meeting.

Encrypted Key Transport for SRTP

    draft-mcgrew-srtp-ekt-00.txt

    David McGrew presented the encrypted key transport (EKT) for SRTP
    proposal and gave an IPR notification on this draft (an actual IPR
    statement was submitted, but didn't appear in time for the meeting).
    EKT does not solve the initial key establishment problem, instead it
    provides secure transport of SRTP master keys, rollover counters and
    other information within SRTCP. This lets SRTP work for  
decentralised
    conferences with minimal control, providing group security and  
handling
    situations caused by SIP forking and early media.

    Steve Casner, asked if the distribution of the EKT key was out of  
scope
    for this specification. David responded that the draft defines a  
way of
    using Security Descriptions to distribute the EKT key.

    Eric Rescorla found the placement of the master key in the  
authentication
    tag "cute". An operational question is if you maintain two different
    keys at the time of switch over. David responded that yes, you  
need to
    and the initial sequence number in the tag tells the receiver  
when the
    new key becomes operational. The best way is to keep both of the  
keys as
    long as you are in within the window of both keys.

RTP over Datagram Transport Layer Security (DTLS)

    draft-tschofenig-avt-rtp-dtls-00.txt

    Jason Fischl presented the proposal to use RTP over DTLS. There  
are many
    drafts in the complete proposal, see slides for complete list.  
There had
    been some off-line discussion between Jason, Eric Rescorla and David
    McGrew and one proposal was to skip the SRTP compatibility mode and
    instead simply use DTLS for key-exchange and then use normal SRTP  
from
    that point. A draft on this will be submitted later.

    Kristian Shrediker (?) asked if you need a TCP/TLS for SIP  
signalling
    and if that creates a NAT problem. Jason responded that no, it  
doesn't
    make the NAT problem worse. Kristian also asked if you need  
another port
    for the RTP/DTLS/UDP. You will need also a port for RTCP, so no  
extra
    compared to RTP.

    Flemming Andreasen asked for clarification about if the  
requirement to
    get the finger print in signalling back before receiving media if  
that
    applies bi-directionally or uni-directional? Eric responded that  
you can
    establish the connection. But the media flowing from Bob to Alice  
isn't
    authenticated until Alice receives Bob's fingerprint.

    Colin Perkins asked the security people present, based on that most
    proposals handle point to point cases, if that is the easy case  
and if
    there is something fundamental in the multi-point case that makes it
    much more difficult to handle? Eric Rescorla responded that it is
    clearly the simple case. While point to point is taught in  
classes the
    multi-point are mostly thought in special cases or not well  
understood
    at all. TESLA is one example how one have to jump through hoops to
    secure multicast. However there are examples like EKT that supports
    multi-cast transport as soon as you have established the EKT secret
    unidirectional. David McGrew commented that MIKEY has gone  
forward in
    MSEC WG and there is interest for the multi-party RTP cases. The  
issues
    with point to point aren't addressed in MSEC and there has been some
    disconnect due to that.

SRTP RCC

    draft-lehtovirta-srtp-rcc-01

    Rolf Blom presented the proposed solution for the ROC initialisation
    problem. The 3GPP MBMS and OMA BCAST work has already adopted this
    solution to the ROC problem and like to see the MIKEY code points  
and
    extension to be IANA registered and could also be useful in larger
    context. Colin commented that as this is used we need at least to  
do the
    IANA registration. The other things will fall into the general  
security
    discussion. Lakshminath Dondeti asked if this is mostly  
orthogonal to
    the discussion in RAI. Magnus responded that despite its urgency the
    general problem should be considered in future discussions. Eric
    Rescorla asked if there is any advantage in this compared to EKT,  
or is
    it simply the problem of it being deployed. Rolf answered that  
these are
    having an overlap in functionality, the main difference in  
regards to
    the ROC is the transport in RTP packets (RCC) and RTCP (EKT)  
which makes
    RCC more robust. Flemming Andreasen commented that RCC's varying  
packet
    sizes may not make all access networks very happy.

    Colin Perkins concluded that the security discussion will  
continue in
    the RAI open area meeting in the afternoon.

				   - + -

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt