[AVTCORE] Draft minutes for IETF 92 - Dallas

[Magnus Westerlund <[e-mail]>]

WG,

The draft version of the minutes are now available. Please review and
send any feedback or corrections on them.

cheers

Magnus Westerlund
Chair

https://www.ietf.org/proceedings/92/minutes/minutes-92-avtcore


IETF 92 - AVTCORE WG meeting minutes
13:00 Tuesday March 24, 2015
Chairs: Roni Even, Magnus Westerlund
Note takers: Mo Zanaty, Varun Singh


WG Status Update
----------------
Chairs
Slides: http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-2.pdf

David Benham raised a question if a minor editorial change to clarify
SFM behavior could be done on
draft-ietf-avtcore-rtp-topologies-update-06. This was agreed to resolve
this before going to IESG.

Kevin Igoe reported that test vectors are being added to
draft-ietf-avtcore-srtp-aes-gcm, which takes time to verify. Other
changes (removing AES-CCM) will be done quickly.

The chairs raised that the WG have a milestone: "Submit Real-Time
Transport Control Protocol (RTCP) in Overlay Multicast for Proposed
Standard". There has been no activity on this milestone for almost three
years. Therefore the chairs proposed to remove the milestone. No
objections in the room, and this will be confirmed on the mailing list.


Circuit Breakers for Unicast RTP Sessions
-----------------------------------------
Colin Perkins
draft-ietf-avtcore-rtp-circuit-breakers-09
Slides: http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-5.pdf

Colin Perkins presented the updates of the document. Jonathan Lennox
asked if there was any assumption of the group size, as that affects the
possibility to keep within a fixed reporting interval. Colin responded
that the minimal 5 seconds interval should be sufficient.

Michael Ramalho on the average loss rate calculation: Consider using an
inverse metric like interval between loss events rather than loss rate.
Colin Perkins responded that we must use only current RTCP RR feedback
without relying on XR or other metrics.

Regarding the minimum sending rate and the open issue if a minimum RTT or
other bounds. Cullen Jennings stated that we should not need to specify
a minimum RTT or packet rate. Magnus Westerlund commented that loss rate
becomes meaningless at very low RTTs, so we need bounds on this.
Cullen responded that it is hard to choose a number that works.
Harald Alvestrand noted that we currently don’t have RTCP feedback per
RTT. Varun Singh asked, is the worst case with low RTT (1ms) with low
packet rate (1 per RTT). Colin responded yes, but unbounded.

The conclusion was to add some text about the limitations at low RTTs.
The authors will run simulations to verify that it works as expected and
will try to have a version ready for WGLC before IETF93.



Multiple Media Streams in a Single RTP Session
----------------------------------------------
Magnus Westerlund
draft-ietf-avtcore-rtp-multi-stream-07
Slides: http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-0.pdf

Mo Zanaty commented for bundled RTP streams with many sources that need
to convey MID, a limit of 4 initial RTCP packets may delay transmission.
Colin Perkins responded that WebRTC is sending lots of initial packets
(STUN/ICE, DTLS, etc.), so we should not easily allow more initial RTCP.
Cullen Jennings commented that we have enough WebRTC implementations to
test this and see what happens. Jonathan Lennox remarked that even with
many sources, all may not need to send immediately, so prioritize the
immediate senders.

Multiplexing Scheme Updates for SRTP Extension DTLS
---------------------------------------------------
Marc Petit-Huguenin
draft-petithuguenin-avtcore-rfc5764-mux-fixes-02
Slides: http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-1.pdf

Eric Rescorla asked why do you need STUN over SCTP? Marc responded for
big (>MTU) STUN messages, it is proposed to use SCTP for handling
fragmentation of the STUN messages. Cullen Jennings commented that STUN
over SCTP is not the right solution, TRAM should reconsider this. Justin
Uberti asked if STUN fingerprints can be used to separate STUN/TURN from
other traffic. Marc responded that it doesn’t solve multiplexing of DTLS
and RTP. Chairs noted that this draft clarifies the mux code points, the
STUN over SCTP issue is for TRAM. Simon Perrault noted that that the
TRAM chairs are very aware of this work.

Eric commented that Multiple registries need to reflect the
overlap/conflicting ranges of each other. There was discussion around
what should happen in the registries. The proposal is to reserve them
and include a pointer to the document explaining the potential issues of
allocating in the ranges used by other protocols.

Jonathan Lennox commented that it would be unlikely but bad if new TLS
content types that never need to mux with RTP use up the remaining mux
space.

Conclusion, support for continue work on proposal except for STUN over
SCTP over UDP that is to be excluded for now.

Requirements for Private Media
------------------------------
Paul Jones
draft-jones-avtcore-private-media-reqts-01
http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-3.pdf

Topology and usage:
Stephen Botzko asked if the conference server can send its own RTP
streams like IVR into the conference session? Paul responded No.
Randell Jesup remarked that IVR can be handled via IVR or other mechanism
end-to-end. IVR type services can be handled by WebRTC data channels.
Chairs remarked that one need to consider any RTP applications, not only
WebRTC. Colin Perkins noted that it should clarify this is only for RTP,
not other protocols. This as SRTP may not be the only solution. For
example, RTP over other security layers like VPN. Paul noted that the
draft explicitly excludes data channels. Colin Perkins commented that
this assumes centralized switch model, which should be stated explicitly
in the draft. David Benham noted that Section 6 specifies this.

Some discussion on the name of the central device is called. Some
clarification of terminology needed.

Trust Model Discussions:

Jonathan Lennox asked if you trust the server from making replay
attacks? Mo Zananty commented that the trust here means the end-to-end
model, but there is also a transport model. Adam Roach asked if we can
relay identities through the central device without making assertions
through the device? Eric Rescorla noted that if you had infinite
bandwidth then you'd not need this system. However, that is not true, so
you need these conferencing servers. Therefore the trust is different.
Emil Ivov noted that Section 7.3 specifies the central switch
assumption.

Discussion of Requirement 10:

Magnus Westerlund (as Individual) noted that one thing to consider is if
a participant can access the media after leaving a conference? Which is
what requirement PM-10 covers. Colin Perkins noted that there are two
problems: one does the participant have access after they have left and
the other is if knows the rooster and deals with reuse of SSRCs (avoid
collisions).

Slide 10 (selective encryption):

Bernard Aboba noted that some RTCP RR, SR, XR would need to be
end-to-middle or things will break. RTP header extensions may also need
confidentiality. Colin Perkins noted that SDES should not be available
for example. Also this information is available in RTP header
extensions. Jonathan Lennox noted that middle boxes must be able to add
RTP header extensions. There are several requirements for these.

Where work will happen:

The chairs noted that with the scope this work appears to need AVTCORE
WG is not a suitable WG. The chairs have discussed with ADs and propose
that efforts are made to create a new WG for this problem and its
solution. Charter and scope will be further discussed on the DISPATCH WG
mailing list. That work is ongoing on this will be presented in SAAG
meeting (Security Area).

Eric Rescorla asked if one can we go faster than next dispatch meeting?
Cullen Jennings commented that one can propose charter on the dispatch
list, approve it on the list.


Solution Framework for Private Media
------------------------------------
Paul Jones
draft-jones-avtcore-private-media-framework-01
Slides: http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-4.pdf

Skipped due to time.

Encrypted Key Transport for Secure RTP
--------------------------------------
John Mattsson
draft-ietf-avtcore-srtp-ekt-03
Slides: http://tools.ietf.org/agenda/92/slides/slides-92-avtcore-6.pdf

John asked the WG if there are any objection to including E2E private
media in EKT scope? Jonathan Lennox remarked that EKT has been in the
progress a long time and not thrilled about delaying EKT further.
Dan Wing added that some people are using EKT. Thus, we need to ask
clearly on the list. Cullen asked if anyone waiting on the EKT draft to
progress to implement it? No response in the meeting.

Decision: Will ask the list about adding E2E privacy in EKT scope.

--- End of Minutes ----



-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------