Subject: [Ice] New version of the proposed charter

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 2 Sep 2015 06:21:02 -0600

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...). 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: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 7 Sep 2015 05:35:15 -0700

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.

> On Sep 2, 2015, at 5:21 AM, Marc Petit-Huguenin <[email-masked]> wrote:
> 
> Signed PGP part
> ---------------------------------------------------------------------------------
> 
> 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?

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).

> --
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 8 Sep 2015 10:44:43 +0000

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

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 <[email-masked]<mailto:[email-masked]>> wrote:

Signed PGP part

Thanks.

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. 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

Milestones

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

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

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

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 09 Sep 2015 12:55:02 -0500

Comments inline:

On 2 Sep 2015, at 7:21, Marc Petit-Huguenin wrote:

> - 
> 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.

I'd like to see more specifics here. There are three milestones--the 
charter text should describe the work items supported by those 
milestones and expected output. If those milestones are assumed to be 
based on existing drafts, please name them.

We also need to be clear on how open or closed ended this is. Is the 
goal to finish specific work and close?
Or do you expect the wg to add new work items in the future as new ICE 
requirements become apparent? (Note that a "standing" maintenance 
working group may get more charter scrutiny than one intended to finish 
and close.)

> 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...). 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
>

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 16 Sep 2015 11:55:00 +0000

> On 09 Sep 2015, at 19:55, Ben Campbell <[email-masked]> wrote:
> 
> Comments inline:
> 
>> 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.
> 
> I'd like to see more specifics here. There are three milestones--the charter text should describe the work items supported by those milestones and expected output. If those milestones are assumed to be based on existing drafts, please name them.
> 
Ok. Will add some more description of active work. This will be based on adopted ICE work in MMUSIC.

Will also try to add some description of what I think the group is working on based on interest in non adopted drafts. This will be subject to my interpretation so some bashing must be done.

> We also need to be clear on how open or closed ended this is. Is the goal to finish specific work and close?
> Or do you expect the wg to add new work items in the future as new ICE requirements become apparent? (Note that a “standing" maintenance working group may get more charter scrutiny than one intended to finish and close.)
> 

My personal preference on this will be to accept work that proposes small changes to improve ICE in subtle ways. And my gut feeling is that we are starting to see the end of this work with the passive-agressive, continuous nomination and shaved ICE initiatives. I would expect those ideas will be trickling in for another year or two. But once that is finished I think it would be suitable to claim victory and close the WG. 

Updated charter will be sent out shortly.

.-.
Pål-Erik

> 
>> 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...). 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
>>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 16 Sep 2015 23:13:42 +0000

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

Signed PGP part

Thanks.

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?).

.-.
Pål-Erik

Thanks,
Alissa

Milestones