Minutes of the ICE Working Group at IETF 97
The ICE working group met at IETF #97 in Seoul, South Korea, on Monday, November 16, 2016.
Chairs: Ari KerŠnen & Peter Thatcher
Agenda:
13:30-13:45 Introduction and Status Update (15 mins, Chairs)
13:45-13:50 Trickle ICE: Are we done? (5 mins, Chairs)
13:50-14:05 ICEbis: Ta conclusion (15 mins, Christer Holmberg)
14:05-14:15 ICE and multi-path opportunities (10 mins, Pal-Erik Martinsen)
14:15-15:00 What's after WG items? (45 mins, Chairs & all)
15:00-15:30 ICEbis: clarifications (30 mins, Christer Holmberg)
Chairs presented working group status slides.
Dual-stack fairness draft done with IESG review but going to
new IETF last call due to incorrect intended status on first time. ICE-bis and
Trickle ICE getting ready for WGLC
On Trickle ICE, authors think there are no open issues left.
Christer Holmberg: When was latest version submitted? Many comments discussed, mostly editorial.
Ari: The latest comments are not yet addressed in the submitted version. New version hopefully out by the end of the month.
Christer presented his slides.
New minimum Ta value of 5ms implemented in the draft based on discussion with transport people.
Ari: This has been the major open issue as long as we have had ICE WG. 5 ms seems to be safe also according to transport folks. Is everybody now happy with the conclusion?
Christer: Mainly Cullen had concerns, but AFAIK he is happy too.
PŒl-Erik: Did some simple tests with simplest devices I could find and was not
able to crash them. At least new ones seem OK with this this.
Ari: Everyone seems OK with this; people nodding in the room.
(returning to discussion at the end of the session)
PŒl-Erik Martinsen presented his slides.
Initial ideas on what we could do when Trickle ICE etc is
finished. Different ways to choose over various paths.
Jonathan Lennox: Many things in RTP assume single path. Assumption on ICE to
converge in one. Comparing to SCTP in WebRTC DataChannel; no one uses the SCTP
possibility to multi-path today.
Christer: In SCTP over DTLS draft discussed same things. You can have multiple
connections, and if use continuous refreshens, going to keep them alive. If you
switch UDP / TCP, suggesting you can switch between them.
Peter Thatcher (from floor): Two things: ICE agent keeping multiple paths
alive. Good things. Another thing: sending media in more than one. For any
multipath, ICE would have to have way to use multiple paths. Is there anything
we need to add to ICE to make that possible? Any reason why can't do this
already? Just need way to re-nominate? Multi-path nomination?
Jšrg Ott: Sounded like ICE would make decisions. Would not be super happy with that. It's the job of the transport on top of ICE. Maybe need sensible API to do this. Show what works, what have appeared/disappeared, etc.
PŒl-Erik: Agreed. The problem with ICE today is the priority of candidates. Tells how to do checklist but also what to pick.
Jonathan: Do we have mechanisms with renomination to do this? Lot of work remaining with multipath RTP.
PŒl-Erik: Should we wait with this until ICEbis is done?
Jonathan: Don't keep adding features to ICEbis now. Let's get it done with current features. Extension story is solid.
Peter presented slides.
Two major options now: 1) keep improving ICE "without major changes" or 2) call ICE "done" and recharter/close.
Jonathan: Would not be in favour of major changes just for the sake of major changes.
Peter: Proposed few minor changes in earlier meeting. But people commented they want major changes. 50/50 at the meeting what people wanted.
Ted Hardie: Agree with Jonathan. Unless "major changes" are detailed
in the charter and milestones, we should not do them. Proposals outside the
charter can be discussed in WG and charter can be amended. Always more than one
way to do this (DISPATCH etc.).
Adam Roach: +1 to Ted's comment
Jonathan: Previously have been focusing getting ICEbis done. And now moving to "we have time for innovative work".
Peter: And if we don't get any new work proposals, we won't be scheduling meeting time
Ben Campbell: As discussed, there are two ways: we can take major things to ICE
WG or at DISPATCH. Things self-contained in ICE makes sense to do here. If
proposed changes significant interaction with other things, it should first be
discussed in DISPATCH.
Ari: Seems we don't have proponents of the major changes in the
room. Maybe the need has gone away; and that's OK. It is a success to say
"we are done" and close the group if needed. We should not try to
invent new work just for the sake of it. What we want to figure out if there is
someone with substantial drive new work. And we still have our milestones to
finish so we are not done this year.
Christer presented his slides.
This is set of "clarifications" but also few technical issues are included.
Christer: On pruning, the text discussed server reflexive candidates but
updates list can contain peer reflexive too. Suggest to go for alternative 2
when pruning peer candidates; having the general statement that "base
replacement" applies to all candidates, regardless of type.
Jonathan L: Is this only editorial? Server and peer reflexive only ones where
base is not equal. How are the statements different?
Christer: NAT assisted candidates in ICE TCP specs need consideration.
Jonathan: For UDP identical but #2 makes sense if TCP considered.
Ari: Also the reason Christer is presenting these, even if editorial, is that we want to check with wider group of people before doing the changes. Is this aligned with your idea and implementations of ICE.
Christer: Suggest we go forward with #2. Will make pull request that people can review on the list. And related issue is to align terminology on "base".
Cullen: Should discuss congestion control.
Ari: The topic was discussed in the beginning (Ta session) but we can revisit that in the end.
On the topic of unfreezing, Christer will have phone meeting after the IETF with Emil. If after the call think it's a big issue and needs to be discussed with the WG, will talk with chairs about having phone conference.
When we removed aggressive nomination, Bernard find out there was some more text that needs edits. Bernard provided pull request. Will be included in next version.
Check list type definitions need clarification. Also, do we need to talk about list types at all? Just say that a list contains peers that are frozen or waiting.
Jonathan: Where are the states used in the doc? If not used, we should remove them. Dead code elimination.
Christer: Some race conditions etc where they are used. Not suggesting removing states.
Jonathan: Need to review the spec -- or have you review and tell if it's used
Christer: Also why we need "valid list". Maybe more than what we want to do here.
What is first media stream? For SDP first m-line makes sense. But should say something for the generic case. Can say it's outside of scope and needs to be defined by usage
Jonathan: Agreed. Also, next one is used in number of places. Using spec needs to define this.
Christer: Could e.g. always want to say through TURN server, while other stream could have host etc. candidates. Maybe first media stream should be the one with large number of candidates?
Jonathan: describing here a small subset of large number of more complicated cases. Peer distributed media case. Foundations of streams disjoint. Need to handle that case. Gets to Emil's table case. There's some text in 5245, bit flaky, on that. Need to have the algorithm properly defined. Need to cover distributed media and TURN cases.
Christer: will not go into details in 5245bis but need to have a mechanism for ICE usage to define what is the "first" media stream.
Jonathan: in distributed media case a certain foundation can only appear on second one. Need to have total order. Which is the first one for each foundation.
Christer: not how it's defined now
Jonathan: could be bug in the 5245. Not how implemented this. Related to Emil table issue. Will discuss on the list.
Ari: will figure out this in a call with Emil, Jonathan, Christer
Jonathan: are triggered checks put to checklist or sent immediately? They're not in checklist.
Christer: go to triggered queue and sent at next possible time
Jonathan: if triggered queue is not empty, next highest priority check can't be performed. So wording here is not quite right.
(no further comments on the issues)
Cullen: was worried about the fact of how many packets we can have in flight; can we have more than 10.
Peter: transport guys wanted three rules, in case of ICE it came down to 1 rule, with 5ms Ta. Long e-mail discussion on this on the list.
Cullen: what was the max bandwidth?
Peter: Same as you would get with the proposed rules. In the ballpark of earlier proposals.
Cullen: and we and ADs are happy with 100 outstanding packets?
Peter: all the experts in the area were
Colin Perkins: don't recall outcome, but if it's 100, would suggest we double check this. 100 packets without feedback sounds big.
Peter: this came from the transport guys. We double checked in the e-mail thread.
Alissa Cooper: you have done exactly the right thing, lots of feedback from Jana and Dave Black. I think you did good job.
Peter: backup plan is to expand to three rules -- they are there, but part of the explanation.
Cullen: thank you for driving this to the ground.
Ben Campbell: we got here by going to TSV ADs who sent us to these guys. So going again would be going in circles. No need to do that.
Ari: seems we are confident going forward and no one is anymore disagreeing on this.
(meeting ended)