Minutes of the Meeting: MMUSIC Working Group at IETF 93
The MMUSIC working group met at IETF #93 in Prague, Czech Republic on Wednesday July 22, 2015 from 17:40 to 19:40 and on Friday July 24, 2015 from 9:00 to 11:30.
The meeting was chaired by Flemming Andreasen and Ari Kernen.
Christer Holmberg, Mo Zanaty, and the chairs took notes on
Wednesday, and Jonathan Lennox acted as Jabber relay.
Suhas Nandakumar, Zahed Sarker, and the chairs took notes on Friday, and
Jonathan Lennox 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 URLs:
● WednesdayÕs
recording:
http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF93_MMUSIC&chapter=chapter_1
● FridayÕs
recording:
http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF93_MMUSIC_II&chapter=chapter_1
Below is the final agenda with links to the relevant sub-sections below:
Wednesday, July 22, 2015
17:40-18:00 Introduction
and Status Update (20 mins, Chairs)
18:00-18:15 ICE
Multihomed and IPv4/IPv6 Dual Stack Fairness (15 mins, Pl-Erik Martinsen)
draft-ietf-mmusic-ice-dualstack-fairness-01
18:15-18:35 Trickle ICE
(20 mins, Emil Ivov)
draft-ietf-mmusic-trickle-ice-02
draft-ietf-mmusic-trickle-ice-sip-02
18:35-18:55 Improvements
to ICE Candidate Nomination (20 mins, Justin Uberti)
draft-uberti-mmusic-nombis-00
18:55-19:25 ICE NAT
experiment results (30 mins, Peter Thatcher)
Friday, July 24, 2015
09:00-09:15 Proposal
for new ICE WG - Discussion (15 mins, all)
09:15-09:35 Proposal for
Fixing ICE (20 mins, Cullen Jennings)
09:35-10:30 ICE bis, NAT
experiment results, and passive-aggressive nomination (55 mins, Ari Kernen,
Peter Thatcher, Justin Uberti)
10:30-11:30 Using the SDP
Offer/Answer Mechanism for DTLS (60 mins, Christer Holmberg)
The chairs presented their slides with an update about activities since the last meeting.
A short plug for Bits n Bytes (Data Centre to the Home -Ultra Low Latency for all) was provided as well (slides).
draft-ietf-mmusic-ice-dualstack-fairness-01
Pl-Erik presented his slides
It was discussed whether a GitHub reference can be used within the draft. It should not be an issue, as the reference is informative.
There were questions to clarify on whether the draft changes the candidate priority, and/or the order in which connectivity checks are performed. It was indicated that the order needs to be the same on both endpoints, even if one endpoint does not support the mechanism.
Related to the text on multihoming, it was indicated that there is currently an ongoing discussion on the RTCWEB mailing list on whether STUN requests must be sent on all available interfaces.
It was indicated that there were objections to the mechanism in a previous meeting. As the individual who raised the objections did not participate in that session, it was asked whether the individual still has the same issues.
It was discussed whether the draft should be standards track or informational. Justin Uberti, Martin Thomson and the author all favored Information. Ari (as chair) asked if anybody disagreed with that - nobody did.
Next Steps
● Draft will move forward as Informational
● Pl-Erik will update the document based on the discussions in the meeting
● An implementation status section will also be added
Reviewers were solicited for the next version of the document and the following people volunteered:
Reviewers: Simon Perrault, Emil Ivov, Jonathan Lennox, and Mo Zanaty.
draft-ietf-mmusic-trickle-ice-02
draft-ietf-mmusic-trickle-ice-sip-02
Emil presented his slides.
According to the authors, both drafts are pretty much done at this point.
There is an issue around use of IP6 Ō::Ķ address with endpoints choking with that.
Conclusion: We will use Ō0.0.0.0Ķ instead of Ō::Ķ.
There was lots of discussion around whether we are now updating RFC 3264 or whether we are rather doing something specific when using trickle ICE. Concerns were expressed around updating RFC 3264
Conclusion: We are not updating RFC 3264; it's an extension with backwards compatible procedures that differ slightly from RFC 3264 (but apply only when you use trickle ICE).
The following individuals volunteered to review the draft:
Reviewers: Pl-Erik, Jonathan Lennox, Brandon Williams.
There was a discussion on the rates of INFO requests, and whether the draft needs to define an interval. EmilÕs proposal was deemed acceptable.
Paul Kyzivat indicated that there are issues with sdpfrag; Paul will follow up on the mailing list.
The following individuals volunteered to review the draft:
Reviewers: Jonathan Lennox and Simon Perrault
Justin presented his slides.
The draft deprecates ICE aggressive nomination, and introduces a new mode which contains the best parts from aggressive- and regular nomination:
● Can send media as soon as a single check succeeds (like aggressive)
● Controlling side has full discretion on which pair is used (like regular)
● Controlled side knows when nomination is complete (like regular)
Justin suggested that there should not be a mechanism for negotiating usage of the mechanism. The reason was that it would introduce a new ICE mode. Instead we would have only one mode.
Justin believes the approach is backwards compatible, however several participants (Jonathan Lennox, Eric Rescorla, Cullen Jennings, Emil Ivov) were not convinced we shouldnÕt negotiate this.
There are concerns around potential clipping issues (Martin Thomson noted the current Mozilla implementation will clip, but it can be fixed) and people would like to see real data.
Justin would like to try without negotiation first and then revisit if it doesnÕt work. Actual testing is needed in order to verify there are no issues, and there were talks about organizing an interop event.
Conclusion
● Justin would like to add it to ice-bis, however for now we will keep it separate and get some implementation experience before deciding whether to incorporate.
● Justin will continue with separate document for now (either split current document or just keep current document).
● The draft needs implementers guidance regarding designing protocols that run on top of ICE. Such protocols should take into consideration that candidates may switch. Need to consider ICE as a virtual socket. If protocol is sensitive to RTT or MTU, needs guidance.
● Justin to talk to Robert Sparks about getting a SipIT event organized before Spring 2016 (which is the currently next scheduled one) to enable more testing.
● Chrome and Firefox will implement and do testing; Cisco (Pl-Erik) will try as well.
Note: no related document.
Peter presented his slides with the results of the tests that have been performed by Google. The results were somewhat surprising and garnered much discussion and a need for further testing.
Some of the questions raised were:
● Experiment may not really test the NAT issue since it's only cycling between 3 server addresses, and creating the NAT binding may have been the limiting factor on the NAT (this has been the case in the past at least).
● In the past, the hypothesis was that we were NAT binding creation limited. Need to run experiment taking that into account (test more NAT binding creations).
The chairs presented their slides with a proposal to form a new ICE WG separate from MMUSIC and then asked for comments from the WG.
Marc Petit-Huguenin: Prefer to keep SDP related ICE work to MMUSIC and move ICE core work to new WG.
Flemming: Split is not clear, for example consider trickle-ice.
Eric Rescorla (EKR): MMUSIC is the ICE WG, inconvenient to have 2 WGs.
Harald Alvestrand: Shutting down WG is good, focused WG is good. support ICE WG creation and it should have the SDP as well.
Jonathan Lennox: +1 to Harald.
Adam Roach: No strong opinion on new WG, but if we create one it should own the entire space; same as in clue.
Pl-Erik Martinsen: +1 to creating new ICE WG; want more attention from transport folks. DonÕt like MMUSIC shutdown, just recharter.
Georg Mayer: If creating ICE WG, not clear there is much work left for MMUSIC; don't want MMUSIC to be shut down
Emil Ivov: +1 on new WG.
Bernard Aboba: +1 on new WG, increases focus. MMUSIC has been around for a long time; may be time to shut it down.
Jonathan Lennox: If DISPATCH existed before ICE, then ICE had already been a WG. MMUSIC did not have much to do before RTCWeb, and thatÕs fine.
Adam Roach: Agreeing with Lennox. MMUSIC survived SIP departure.
Alissa Cooper: One of the advantages we get is additional chairs and more machinery to do the work. Can split the groups and leave MMUSIC as caretaker. If MMUSIC goes dormant, then we can shut it down. Doesn't have to be very active. Can always shut it down at some point in the future.
Ari: MMUSIC currently has 8 non-ICE WG items and will still stay even if we split ICE.
Cullen: Not clear on what people want; new group, two groups or one group?
Martin Thomson: Support a new WG, but don't call it ICE, call it ice-bis. Regarding SDP, the ICE WG should own it.
Jonathan Lennox: ICE needs more input from transport and transport folks might not be happy to sit for SDP things if in MMUSIC.
EKR: Name it ice-bis. Agrees on WG should own SDP.
Andy: +1 on Ekr. No feelings on whether MMUSIC should die or not, but worried on how these small WGs meet.
Ari: There would be one session for each instead of two MMUSIC sessions. Not much different to what we have now.
Ben Campbell (as individual):
● Seems most people are agreeing with a WG focusing on ICE.
● Seems there are mixed opinions on whether MMUSIC should continue.
● Probably in favor of continuing MMUSIC as well for now and re-evaluate as we see the amount of work needed.
draft-jennings-mmusic-ice-fix-00
Cullen presented his slides on Vanilla ICE.
slide-2
Lennox: Does "not interoperate" mean didn't bother to implement?
Bernard: Many of these were proprietary, but WebRTC focuses more on interoperability (vendors now care about interoperability with other vendorsÕ products).
slide-3-4
Pl-Erik: Bundle makes ICE lot easier.
Cullen: Agreed that we solved many problems; have RTP/RTCP multiplexing as well.
Bernard: Adds on timing leads to un-routable things like IPv6 adding more to timings with lots of retransmission.
Cullen: Agrees. But impossible to do global pacing.
Peter: Supports removing non mux RTCP.
Emil: Common to operate without TURN, uses media server.
Bernard: Supports TURN server usage since it fixes lot of problems. TURN is incredibly valuable.
Peter: Supports similar idea.
Cullen: How much of it is WebRTC specific or generic?
Justin: We don't fully understand the problems and going to something new is not a good idea.
Brandon: Agrees with Justin. Also, what is being proposed is incremental update rather than defining a new thing. We can use well distributed relay service to trickle the candidates.
Bernard: Agrees with Justin that we understand ice with IPv4, but not much of IPv6. For cases with TURN mobility, CullenÕs proposal is a better idea, so don't rule out.
Martin Thomson: We need to understand how do we scope it. Is it just a connectivity check or is it a new way everyone should do ICE. Need to get more understanding of this.
Cullen: This is not a final solution, we need to understand it more. But it is a very small change.
Next steps is to expand the draft to add more details.
This is not for ICE bis but more for future version.
draft-ietf-mmusic-rfc5245bis-04
draft-ietf-mmusic-ice-sip-sdp-05
Connectivity Check Pacing
Ari: Want to find out how "low can we go". Want to hear more from Peter's experiments on that, come up with a number we can agree on, and then start the discussions with transport folks.
Peter presented his slides on NAT experiment results (ŌWhat Next for TaĶ).
Pl-Erik: What's the consequence of setting it too low?
Ari: Two main issues; how fast can the NAT create the bindings and need to avoid overloading your link and dropping connectivity checks due to congestion.
Justin: The packets actually have a decent size; the bandwidth consumed is actually significant. At 5 ms you are over 100 kbps bandwidth usage for connectivity checks.
Emil: Think there are two separate constraints. Should not be tied to any particular bandwidth number. Question is "could this damage your network"? Tests seem to indicate no, but we don't know. We don't know of an optimal number that will work best. We do need to avoid any value that we know will create problems though.
Cullen: Should not look at the link/interface to determine bandwidth you can use, because you do not know about any subsequent links.
EKR & Emil: <comments about attack and being application specific>
Justin: Be careful with just putting a number in there, because people will just use it without thinking about it.
EKR: Probably need to combine with some kind of circuit breaker
Justin: Have to consider DoS attack usage and other malicious implications.
Cullen: A bunch of constraints; security, congestion/packet loss, NAT binding creation rate. Need to meet all of those constraints simultaneously, but don't know enough about them all yet.
Action/conclusion: Need to write down all the constraints and figure out recommendations about them all.
Harald: Eliminate second alternative; blasting at wire speed is probably not a good idea.
Peter: Asking if we have enough experiment results at this point?
Ari: Would like to see more experiments
Peter: See "What next for experiments" slide; seems Ari is suggesting the second one.
Cullen: Would like to see experiments that show something on NAT binding creation rates.
Pl-Erik: Think bandwith discussion is a red herring. Need to look at different metrics.
Randall Jessup (via Jabber): Need more experiments.
Cullen: On arrival rates; should look at sending times on sending side and receive times on receiving side to correlate what happens in between.
People asking for the code Cullen originally wrote when doing NAT experiments 10 years ago. Cullen will look for that.
Justin: Can somebody write down the exact experiments people want done. Cullen volunteering to help write down.
Action: Looking for volunteers to help write down (besides Cullen).
EKR: Ta isn't the only control we have. Comfortable with aggressive numbers as long as you have a throttle mechanism as well.
Conclusion:
● Need more experiments.
● People to send specifics around what they want experiments for to the mailing list.
Bernard: There are lot of things that have been revisited in the transport area, but it's all based on data.
Pl-Erik: And we need the transport folks to comment on that.
Justin presented his slides on passive-aggressive nomination (ŌShaved ICEĶ)
Motivation (see slides): One issue today is around packet size (bandwidth usage).
Proposal: Use of passive-aggressive nomination and smaller packets.
Looking at how we can reduce the ICE packet size.
EKR: No reason why MAC needs to be big. Less happy about stuffing hash in the transaction ID.
Cullen: Useful for mobile cases to reduce the size. We need measurements in this direction.
Lennox: ufrag is needed to secure against off-path attacker doing fake connectivity checks.
Next steps: We need to discuss more on the approach and get back. Look further into what we can do with ufrag, etc. How much can we reduce packet size safely?
Ari presented his slides on ICE bis.
NAT64 Issue
Simon: Keep things explicit. No need to do prefix discovery. Just send the STUN request and see if it is IPv4 Address.
Lennox: Prefix discovery is needed when sending checks from the IPv6 address to IPv4. Other issue is that 464xlat will be entirely redundant candidates; might need some logic to say your v4 cand and v6 candidate is 464xlat.
Cullen and Adam agreed on having prefix discovery requirement.
Magnus: People saw this as limitation regarding address independent mapping. We may see address depending mapping behaviour too.
Conclusion:
● Mention the issue of NAT64 in ICE-bis.
● Use STUN as base mechanism.
● Should do prefix discovery because of address dependent filtering.
Cullen: Have some concerns with prefix discovery - need to think more about it.
Adam: Is Cullen concerned it will make it worse? ICE is just trying a bunch of different things to find something that works.
Cullen: Worried it may make things worse for some types of IPv6 NATs.
Jonathan Lennox clarified his proposal; Cullen seemed OK with that.
ice-restart issue
Lennox: ice-restart is misunderstood as the way it is. Needs to be editorial work on explaining why ice-restart is not a big deal and re-use most of the resources.
Future of ICE (nominations) - Justin & Ari
Need more analysis to understand continuous nomination. Discussion on going.
Justin: still more investigation need to be done before we can come up with a concrete solution. Then decide where to go from that. How ICE will work with multipath. Will not be backward compatible with current passive-aggressive.
Lennox: Parts of shaved ICE in the scope of TRAM WG. Ice-bis can define the number of bits of integrity needed or so reasonable to have in the scope of stun-bis. For others - we need to analyze more.
Emil: Which option maintains backward compatibility. Can we have impact without breaking compatibility. These are in the scope of ice-bis.
Bernard: Many things are in the scope of ice-bis or trickle ICE. Even continuous nomination can be enabled with trickle ICE. Just update trickle ICE for that as clarification.
Cullen: Go with bulk changes when doing ice-options rather than making several changes.
Ari: Agreed.
Emil: Implementers should treat ICE as it is providing a virtual socket. Important to disassociate from anything physical (like interface), which may change. Should be clear about this in ice-bis.
Bernard: TCP cannot treat it as virtual socket.
Justin: Having some guidance around proper socket use (implementation guidelines) would be beneficial.
draft-holmberg-mmusic-sdp-dtls-01
Christer presented his slides.
Slide 4-5
Justin: DonÕt look at ufrag; just use connection existing or new to decide if it is restart or not. Make it explicit.
Crister: Today ufrag is needed to make the decision; but agrees with Justin's suggestion.
Peter: Agrees with Justin. What happens if the attribute is not there?
Christer: Default is new as defined for TCP/TLS. Thus define there would not be a default value.
Peter: Prefer defining behavior to be existing if not there.
Cullen: Need to be backwards compatible; work with legacy even though bit complicated.
Lennox: When fingerprint change, donÕt use existing. Need to consider possibility of multiple fingerprints; it is needed to maintain the currently used fingerprint to make the decision to accept or reject the connection.
Christer agrees, but havenÕt considered multiple fingerprints yet.
EKR: Has anybody implemented the old way yet? If not, then why worry about backwards compatibility?
Cullen: Not sure we can forgo backwards compatibility. Need to think about that more and hear from more people.
Justin: Propose that fingerprint goes away, ufrag changes and ice restart --> keep the connection:new or keep it connection:existing otherwise.
<more discussion>
Chairs asking room for interest in the work
● Create a milestone; Large hum in favor; nobody opposed.
● Adopt the draft: Large hum in favor; nobody opposed.
Conclusion
● Chairs will work with ADs on creating a new milestone.
● Assuming OK, we will adopt Christer's document for that.