Minutes of the ICE Working Group at IETF 95
The ICE working group met at IETF #95 in Buenos Aires, Argentina on Thursday April 7th, 2016 from 14:00 to 16:00.
The meeting was chaired by Ari KerŠnen and Peter Thatcher.
Jaime JimŽnez, Brandon Williams, and the chairs took notes and Brian Rosen acted as Jabber relay.
The meetings were broadcast live and recorded by the Meetecho team. The recordings of the sessions are available at the following URL:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_ICE&chapter=chapter_1
Final agenda with links to the relevant sub-sections:
14:00-14:15 Introduction and Status Update (15 mins, Chairs)
14:15-15:00 ICEbis (45 mins, Christer Holmberg)
15:00-15:30 Trickle ICE (30 mins, Justin Uberti)
15:30-15:50 Network Cost (20 mins, Peter Thatcher)
15:50-16:00 Renomination (10 mins, Peter Thatcher)
Chairs presented ICE working group status.
"Dual Stack fairness" draft publication to be requested shortly. Christer Holmberg is the new editor of the "ICE bis" draft and will drive the discussions. ICE bis and Trickle ICE are main deliverables from the group and discussed at the meeting. If we have time after ICE bis and Trickle ICE, we can discuss also the two new drafts about Network Cost and Renomination.
Christer presented his slides.
Cullen J: Some things don't have comfort-noise, like video codecs.
Roni Even: noop expired in 2007 due to IPR issues.
Some opinions that we don't need to handle non-ICE in ICE, to RTP no-op isn't critical.
Christer: Do we want to talk about the non-ICE case or not?
Ari: Should we keep this text or do we completely remove it?
Jonathan Lenox: Informative reference to RFC 6263 should be the most, not having anything is fine too.
Ari (as chair): We seem to have consensus to remove discussion of RTP keep-alives for non-ICE peers.
Ekr (Eric Rescorla): 50 ms is too high for default
Cullen: That minimum is too low according to our measurements. Some measurements would be needed.
Justin Uberti: Lowering it to 10 or 5 didn't have negative effects. Need to control aggregate bandwidth.
Brandon: Is this supposed to be mandatory or guidance?
Ari: the minimum value has to be "MUST" the default value could be "SHOULD". If a usage knows more, they could define a different default.
Ekr: support for 5ms min, 50ms default, no requirement for signaling.
Magnus Westerlund: May be trouble if the two sides don't agree. How they agree doesn't need to be defined.
(jabber): Which is the reason not to make 20ms as default.
Ari: To be conservative.
Cullen: There are 3 things to consider for the minimum: how fast NATs can create bindings, the uncongested properties of the channel, the timing constraints of the application
Magnus W: 50ms is reasonable
Justin U: Prevailing factor is bandwidth consumption, not NAT behavior.
(jabber): 20 ms is the defacto today, -1 to introducing 50ms as new default.
Justin U: we could say 50ms is bandwidth guided, we could leave it to the application.
Some discussion of what an appropriate bandwidth limit would be.
Magnus: Concerned about the fact that there's no cong control in ice to drive behavior change if packet rate is too low.
Chairs took hums on whether RTP and non-RTP traffic should be treated differently (i.e., keep the current split) or in a similar way when pacing value (Ta) is calculated.
HUM1: if you would like to keep it currently with diff between RTP and non-RTP (no one hummed)
HUM2: If you want to remove the difference. (several hums)
Conclusion: There was consensus in the room on removing the split.
Justin U: Volunteered to provide tables for the draft regarding impact of selected Ta on bandwidth
Chairs took a hum on minimum value for the pacing value.
HUM3 on minimum value, must not go below 5 (several hums + 2 jabber).
HUM4 on minimum value, keep discussing (weaker hum).
Cullen: Measurements are still desired.
Justin: Disagrees: we don't have measurements.
No one volunteered to produce measurements.
Ben: Suggests that we pick a date as cutoff for new data. If no new data, go with the hum.
Ari: aiming for shipping the draft end of this year. IETF Berlin date to close last open issues.
Justin: people with p2p apps could use a toggle switch for Ta. Chrome could add a switch if others would use it for testing.
(jabber): 2 people volunteer to do it...
Cullen: Default should be the same as minimum.
(jabber): +1 for same as default
Jonathan Lennox: Experience shows people will use the minimum value.
Ari: It would be a SHOULD for the default.
Ben: "SHOULD" leaves the implementor to have other good reasons.
Conclusion: going forward with 5ms while waiting for more information
Chairs took a hum for the default Ta value
HUM5: 50ms default (Reasonable hum)
HUM6: min (5ms) default (2 from jabber)
HUM7: Something else. (1 from jabber)
Conclusion: 50 ms default was preferred. To be confirmed on the list.
Issue: Aggressive nomination seems redundant since spec already allows you to send media before nomination. If we deprecate it, how do we do it to be backward compatible?
Option 1: receive-do-not-send
Option2: use ice-option
Jonathan L: May need to deal with both to handle implementers who ignored "MUST not use aggressive with unknown ice option"
Chrome and FF don't implement to spec regarding unknown ice options, but both could add it.
Doing both seems the safest thing.
Justin: Can we find a way to signal this without burning an option?
Jonathon: If first check has use-candidate, remote peer is using aggressive. Handle accordingly.
Chairs took a hum on going forward with using both options at the same time.
HUM 8: Do Something else (no hums)
HUM 9: If you are OK with that (medium hum + 4 jabber)
Conclusion: consensus in the room to do both.
Conclusion: start discussion on the list with the Ice-option. What ice option name?
Due to lack of time to be taken on the list.
Justin presented his slides.
Problem: if a trickle candidate exists but with different types.
Recommendation is to replace existing trickle candidate if new candidate comes with a higher priority. RFC 5245 has the same issue.
Conclusion: Apparent (no hums) support for recommendation. No direct objections. Also support for similar RFC5245bis update.
Two candidates have different foundations and exists on two different components. One of the components does not automatically unfreeze due to different foundation.
Recommendations: Rely on end-of-candidates indication to trigger unfreezing OR don't solve it, use rtcp-mux instead.
Unfreeze first thing that comes in based on ordering. If you get a second also unfreeze. With multiple candidates on the same foundation, if a candidate that comes later in the order arrives first, unfreeze that candidate. If a candidate from earlier in the order arrives later, unfreeze that one too.
EKR: There are two invariants in the current draft
(1) That candidates are delivered by the signaling in the order they are emitted by the sender
(2) That you only send out candidates in the media stream order within the same foundation (in Section 8) which requires that the sender reorder candidates from where they are gathered.
The proposed unfreezing algorithm here removes the need for #2.
Problem: An ICE restart happens before candidate gathering is complete. How do you trickle those candidates?
Recommendation: Signal a way to tell whether the candidate is from before of after ICE restart. For example signal the ufrag in the candidate.
Explicit option seems to have some support. Just need to figure out how to capture it.
These topics were left for off-line discussion. Everyone is encouraged to read the drafts and the slides (network cost and renomination) since these are topics that might be relevant future work for the ICE WG.