Minutes for AVTCORE at IETF-96
minutes-96-avtcore-6

Meeting Minutes Audio/Video Transport Core Maintenance (avtcore) WG
Title Minutes for AVTCORE at IETF-96
State Active
Other versions plain text
Last updated 2016-08-29

Meeting Minutes
minutes-96-avtcore

   AVTCORE WG
==========
Note Taker: Marc Petit-Huguenin

Chairs:
Roni Even
Magnus Westerlund


Chairs Slide:
-------------
Roni Even
Magnus Westerlund

https://www.ietf.org/proceedings/96/slides/slides-96-avtcore-0.pdf

Colin Perkins noted regarding draft-ietf-avtcore-rtp-multi-stream-optimisation 
that it may require update for the format of the Reporting group ID. 
The reason is that it is unnecessary verbose, as it will be included in 
regular reports. The RMTCAT WG's work on congestion control feedback
has unearthed this issue. A Proposal for the change needs to be sent 
to the WG mailing list and should achieve consensus before 
decision is made to pull the document from the RFC-editor queue.

ACTION ITEM: Send proposals to the mailing list before pulling it.

Roni Even informed that for draft-ietf-avtcore-aria-srtp the writeup 
was updated before the meeting. draft-ietf-avtcore-aria-sdes ready 
for last call. Ben Campbell asked if the shepherd want to synchronize 
these? Roni responded that it is not needed. 

ACTION ITEM: Magnus to update draft-ietf-avtcore-multiplex-guidelines


Multi-Parth RTP 
---------------
Varun Singh
https://www.ietf.org/proceedings/96/slides/slides-96-avtcore-6.pdf

Taxonomy has been updated. 

ACTION ITEM: New taxonomy needs reviews, especially from the 
taxonomy authors.

ACTION ITEM: The draft needs some more reviews.

ACTION ITEM: People could think about possible solutions about 
the interface advertisement in RTCP.

Emil Ivov commented that the WG should revise its timeline for 
publishing this. The reason is that multipath path establishmenthas
has not yet seen any work in ICE WG. The solution should not perform
interface advertisments in RTCP. It's not only about about interfaces, 
it's also about candidate pairs.

Varun stated We can do it in RTCP until there is a point where 
people know how to do it. If people find a better to do it, we'll 
just update the draft.

Bernard Adoba commented that we do all these things in ICE to 
allow passive/aggressive nomination. We need to think carefully 
what happen when these paths shift. Varun responded the congestion
control has the responsibility to figure out bottleneck. So perhaps 
it is the congestion control responsibility to choose to use them 
or not.

Cullen Jennings responded that the document should be published 
as it is stand-alone. Peter Thatcher commented that Multipath ICE 
is not really (?) yet. Several in the room supported it going 
forward as it targets experimental status. 

Magnus Westerlund to send text on security text on the issues of 
potential two time pad. Packets are sent on different paths are 
different, even if duplication of payload and meta data. Need to
check that the IV used on these packets are unique. 

ACTION ITEM: Security consideration is lacking. Magnus Westerlund
to contribute.


RFC5285bis 
----------
Roni Even
https://www.ietf.org/proceedings/96/slides/slides-96-avtcore-1.pdf

Jonathan Lennox commented that document need to be sure it is clear 
with the difference between SDES header extension which change 
occasionally, and things like timecode that are sent all the time.
We need guidance on things that never change, change occasionally 
or that change all the time. Ronie responded that the question was 
more on how many times to send it to have reliability. Jonathan 
responded that if it changes all the time, the reliability 
considerations is not relevant.

ACTION ITEM: Authors need clarify differene.

Circuit Breaker 
---------------
Colin Perkins
https://www.ietf.org/proceedings/96/slides/slides-96-avtcore-2.pdf

Bernard Aboba remarked that Varun Singh has raised WebRTC API (W3C) issue. 
What does the app developer need to know. Do you get an API, or can they 
restart it? Does this document need to make more clear recommendations.
Cullen Jennings noted that the existing spec says that this is the 
browser must enforce, not the Javascript. Inventing a notification is 
for WebRTC WG (W3C). Needs clarification for WebRTC who is responsible 
to notice this. 

ACTION ITEM: Log a bug in WebRTC saying that we need an event when 
the circuit breaker blows.

Bernard commented that he from a WebRTC application could make the
circuit breaker triggering go away using a ICE Restart. Colin asked 
how this relates to this draft. The issue is that it is not clear. 
Colin pointed to the "should not be restarted unless..." text. 
Varun Singh remarked that it could be that audio and video are on 
the same transport and the circuit breaker kicks for the video and 
audio is still going. The app may want to look and see that the audio
is fine and in the future the app may reenable the video. The 
notification is useful in that case. In the case that ICE goes away 
and circuit breaker triggers, you get two events, and the app can 
just ignore the second one. Colin responded that from the point of 
view of this draft, it does not matter. It matters for WebRTC.
Jonathan Lennox commented that one thing that is clearly count as a 
path change, is when ICE restart has found a new working connectivy pair.
Cullen Jennings responded that the current text is sufficient. Circuit 
breaker is working on stream level. So if you change interface you have 
a new 5-tuple the RTP Stream goes over. Thus different state. Martin 
Thomson noted that this discussion would be valuable to have 
explicit in the draft. Please ensure to check in the text. Peter Thatcher
noted that with that rule, if after an ICE restart only the port 
changes, would that retrigger the circuit breaker? Colin noted what 
it says is that if you have a reasonable expectation that you are on 
a different path and different congestion conditions then you restart.
We can't give precise guidance in each case.

ACTION ITEM: Someone to suggest text

Regarding the ECN issue. Jonathan Lennox noted that a future memo may 
possible never be published, ensure correct formulation. 
There was consensus in the room to go with the proposed text for the 
ECN issue.

ACTION ITEM: Add the text.



PAYLOAD WG
==========
19.7.2016
Note takers: Marc Petit-Huguenin, Magnus Westerlund
Jabber relay: Jonathan Lennox

Payload Status Update
---------------------
Status of VP9 payload in draft-ietf-payload-vp9-02.
Jonathan Lennox: The payload itself is done. The document need the 
offer/answer section and more explanatory text.

Draft-ietf-payload-melpe – will start WGLC after the meeting – please review
New WG document  draft-ietf-payload-rtp-vc2hq need reviewers

RTP Payload Format for Non-Interleaved and Interleaved Parity FEC
-----------------------------------------------------------------
Varun Singh
draft-ietf-payload-flexible-fec-scheme-02
 
There is an IPR statement
ACTION ITEM: Send comments about CISCO IPR declaration, if any, to the list.

Some comments about the IPR:
Jonathan Lennox(JL): It is easy to use it in a mode that does not 
protect multiple source. 



Varun Singh(VS): If you remove that feature, yes.

Bernard Adoba (BA): It is not even clear how this can be used.

VS: No, because there is multiple SSRC in the packet.

Payload header 
Varun Singh: There are bits that can be removed, for rtx the SSRC count 
is 1 and can be redundant if the R-bit is 1 (retransmission) which 
provides even lower number of bytes in the payload header see slides 4 
and 5 in the presentation (slides-96-avtcore-4.pdf) 


Mo Zanaty(MZ): We can eliminate length recovery too.

BA: It is desirable to have retransmission as well, but to do that you 
really have to kill RTX. 

VS: If we want to save more bits we should do a different format.


JL: I would push back on moving the TS recovery field.

VS: Probably need to redefine it

MZ: Exactly what Jonathan said.

ACTION ITEM: Send to the list


ACTION ITEM: Check the decision about reed-solomon/raptor in Yokohama. 
Chair comment for minutes: reviewed the meeting notes could not see any 
text about the topic 

After discussion:
ACTION ITEM: Separate media registration

ACTION ITEM: reed-solomon/raptor on separate drafts.

JL: Do we know if we are doing FEC before or after SRTP?

VS: FEC on unencrypted media.


RTP Payload Format for HTTP Adaptive Streaming   
----------------------------------------------
presented by Rachel Huang, see
draft-wei-payload-has-over-rtp-00.txt 

Varun Singh: I am not sure why there would be an issue with congestion 
control. About fragmentation the only thing I could suggest is using 
smaller chunks. For the manifests, the decision should be made by the 
existing technology. 

Roni Even: For the manifests it is about how to provide the information 
for the multicast groups. 

Magnus Westerlund: What is really missing the URI format.

Colin Perkins: I thought what was proposed was simpler.
Do you really need the manifest files? The answer is no.
Use the SDP.

VS: The thing that could be done is the fragmentation of the packets, 
the other things are out of scope. 

ACTION ITEM: Continue this discussion.