Re: [Ice] New version of the proposed charter

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Inline [TR]
From: Ice [mailto:[e-mail]] On Behalf Of Pal Martinsen (palmarti)
Sent: Tuesday, September 08, 2015 4:15 PM
To: [e-mail]
Cc: Marc Petit-Huguenin; Alissa Cooper
Subject: Re: [Ice] New version of the proposed charter


On 07 Sep 2015, at 14:35, Alissa Cooper <[e-mail]<mailto:[e-mail]>> wrote:

Thanks Marc. It would be useful to hear from folks if they think this is ready to go or needs further editing. I have one question and some comments below.

Question: I thought there was discussion about clarifying that the SDP work will remain in MMUSIC? I think that would help.


The MMUSIC chairs opened up that discussion on the MMUSIC list. The outcome of that discussion can probably be put into this charter for clarity.


On Sep 2, 2015, at 5:21 AM, Marc Petit-Huguenin <[e-mail]<mailto:[e-mail]>> wrote:

Signed PGP part
Please find below a new version of the proposed charter, trying to take in account all the comments so far.

The discussions are taking place in the ice mailing-list, please do not cross-post.

Thanks.

---------------------------------------------------------------------------------

Charter for Working Group

Interactive Connectivity Establishment was published as RFC 5245 in April 2010. Until recently the protocol had seen rather limited deployment. ICE was slow to achieve widespread adoption, as other mechanisms were already being used by the VoIP industry. This situation has changed drastically as ICE is mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web.

Interactive Connectivity Establishment (ICE) is at the same time a NAT traversal technique, a multihomed address selection technique, and a dual stack address selection technique that works by including a multiplicity of IP addresses and ports in both the request and response messages of a connectivity establishment transaction. The IP addresses and ports provided by each side are paired and tested by peer-to-peer connectivity checks until one of these pair is selected to transport data. ICE follows the end to end principle where the clients themselves discovers, test and choose the network path to use. It makes no assumptions regarding network topology on the local or remote side.

ICE was originally defined for the Offer-Answer (RFC 3264) protocol used by SIP (RFC 3261). Later XMPP (XEP-0176), RTSP (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and other realtime media establishment protocol have used the protocol. ICE is also used by non-realtime media protocols, like HIP (RFC 5770) and RELOAD (RFC 6940).

The goal of the ICE Working Group is to consolidate the various initiatives to update ICE to make it more suitable for the WebRTC environment but also to all the current usages of ICE. ICE is an application controlled protocol that leverages a set of network defined protocols. The STUN (RFC 5389), TURN (RFC 5766) and related protocol work done in the TRAM working group must be closely synchronised with the work in this working group. Synching with other network related working groups to make sure existing mechanisms like QoS, congestion control and other networking mechanisms still work would be essential if we want to improve how ICE works (MIF, TAPS, TSWG, HOMENET, etc…).

I think the description of how the ICE WG will interact with these other WGs needs to be a little more specific that “synching with” an open-ended list of WGs. Is it really the case that the ICE WG intends to do something specific with respect to these groups, or rather that the ICE WG will ensure that updates to ICE allow for continued support of QoS and congestion control mechanisms generally?

I agree that weak promises regarding synching work and an open list of WGs is not ideal.

I have a nagging feeling that work in MIF and Homenet would affect how ICE works.

[TR] MIF WG has already finalized the new architecture, ICE work needs to catch up. I guess a draft discussing MIF + ICE may be required soon.

-Tiru


Working closer with them might help us to avoid future problems like what recently happened in rtcweb (What? Do ICE send STUN packets on all available interfaces? Not only the default route?).

I think this has to do with closing the somewhat artificial IETF gap between application protocols and “pure” network protocols. ICE is a nice example of a protocol stack that fits in the middle between the two. However it should not be the ICE WGs sole responsibility to do the synching. One of the goals of creating a new WG is to create more interest from the “network people”. Somehow I think the charter need to reflect that. How do we write a charter that invites the right set of people to contribute?

First attempt on charter text:
"To avoid interoperability issues and unwanted behavior it is desired to increase the interaction with other working groups dealing with network protocols closer to the wire. Example of such work may be, but not limited to; issues regarding multi-homing, multi subnet and prefixes, QoS, transport selection and congestion control.”

I do not like the words “desired to increase interaction”, but have no idea how to phrase that intention in a charter.

.-.
Pål-Erik


Thanks,
Alissa


From the application side, the users of ICE, there is a need to make sure what is specified is actually usable. Getting input from the application working groups will be essential (RTCWEB, HIP, MMUSIC, P2PSIP).



Milestones

    Jun 2016 Submit Dual-stack Fairness with ICE as Proposed Standard
    Apr 2016 Submit a revision of ICE (RFC 5245) as Proposed Standard
    Jan 2016 Submit Trickle ICE as Proposed Standard

--
Marc Petit-Huguenin
Email: [e-mail]<mailto:[e-mail]>
Blog: http://blog.marc.petit-huguenin.org<http://blog.marc.petit-huguenin.org/>
Profile: http://www.linkedin.com/in/petithug


_______________________________________________
Ice mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ice

_______________________________________________
Ice mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ice