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

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.