Subject: [MMUSIC] Do We Need an ICE Alternative ?

From: Flemming Andreasen <[email-masked]>
Date: Tue, 15 Nov 2011 07:49:16 -0500

Greetings

Over the past several years, the MMUSIC WG has developed and 
standardized ICE (RFC 5245) as the mechanism to enable NAT traversal and 
IPv4/IPv6 transition for Offer/Answer based protocols (such as SIP). 
Alternative NAT traversal mechanisms exist, and others have been 
proposed, however they have either been limited to specific deployment 
topologies (e.g. symmetric RTP or STUN by itself) or required some level 
of network support (e.g. an ALG of some sort). Similarly, for IPv4/IPv6 
transition, RFC 4091/4092 (ANAT) defined an alternative solution that 
was deprecated following MMUSIC and SIPPING WG discssion and consensus 
at IETF68 (in 2007):

     http://www.ietf.org/proceedings/68/minutes/mmusic.txt
     http://www.ietf.org/proceedings/68/minutes/sipping.txt

Several years have passed and we have been getting more implementation 
and deployment experience with ICE. However, we have also seen 
suggestions for alternative solutions, with recent examples including 
the ALTC draft for IPv4/IPv6 transition and the latching mechanism for 
NAT traversal:

     Link to ALTC draft:
     https://datatracker.ietf.org/doc/draft-boucadair-mmusic-altc/

     Link to latching mechanism (Section 5.7 in old version of loopback 
draft):
     http://tools.ietf.org/id/draft-ietf-mmusic-media-loopback-15.txt

Alternatives, that generally have a more limited scope than ICE, keep 
popping up every now and then, and it seems that at least some set of 
people are not happy with the current ICE solution. So, we would like to 
understand from the working group if there are issues with ICE and if we 
need to explore alternative solutions for NAT traversal and/or for 
IPv4/IPv6 transition.

Our goal as a standards organization is to enable interoperable 
products, and having multiple different standards for the same problem 
or multiple different standards for specific instances of a general 
problem is not conducive to that. If we have to revisit one of the 
standards for a given problem space, we ought to be careful and 
understand what are the issues that we have with that standard. 
Furthermore, if we are to come with alternative solutions for that 
problem space, we have to ensure a clear understanding of what has 
changed since the last time we created the standard, what are the new 
set of requirements to satisfy, and which of the old requirements no 
longer apply.

So, we would like to sense the WG for opinions in this matter

Thanks

     Flemming and Miguel (MMUSIC chairs)

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 16 Nov 2011 03:57:21 +0100

Hi,

My understanding of previous discussion.

During IETF77 we discussed both the altc draft (http://tools.ietf.org/html/draft-boucadair-mmusic-altc-03) and the alternative ICE-microlite draft (http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-02). 

The conclusion of this discussion was that there was no way forward for either of these drafts as stated in the minutes of this meeting (http://www.ietf.org/proceedings/77/minutes/mmusic.html).

However I notice that draft-boucadair-mmusic-altc continues to be updated although there has been no discussion or even notification of updates on the MMUSIC list. 

Therefore I would like to know what is the current status and intention regarding the altc draft?

During IETF80 draft http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-01 was presented with the intention of starting a discussion on some of the barriers to deploying ICE. The feedback we obtained was that the requirement for an updated offer in ICE was not really that strict, even though it is mandatory in the draft, and implementations are not always implementing this anyway.  The conclusion I understood was to continue to document and discuss the problems and if necessary if there are enough issues raised update ICE.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Flemming Andreasen
> Sent: 15 November 2011 20:49
> To: mmusic
> Subject: [MMUSIC] Do We Need an ICE Alternative ?
> 
> Greetings
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Nov 2011 06:26:02 +0000

> Therefore I would like to know what is the current status and intention regarding the altc draft?

It's now an independent submission to the RFC editor, outside of IETF.  It was updated based on comments back from the assigned reviewer.

If you have comments/edits/changes/concerns you'd like to make on the altc draft, please email the authors - we'd love to hear them and address them.

-hadriel

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 16 Nov 2011 07:47:15 +0100

I assume then that the draft should no longer indicate that it is "Standards Track".

Regards
Andy

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: 16 November 2011 14:26
> To: Hutton, Andrew
> Cc: Flemming Andreasen; mmusic
> Subject: Re: [MMUSIC] Do We Need an ICE Alternative ?
> 
> 
> > During IETF77 we discussed both the altc draft
> (http://tools.ietf.org/html/draft-boucadair-mmusic-altc-03) and the
> alternative ICE-microlite draft (http://tools.ietf.org/html/draft-
> hutton-mmusic-icemicrolite-02).
> > The conclusion of this discussion was that there was no way forward
> for either of these drafts as stated in the minutes of this meeting
> (http://www.ietf.org/proceedings/77/minutes/mmusic.html).
> > However I notice that draft-boucadair-mmusic-altc continues to be
> updated although there has been no discussion or even notification of
> updates on the MMUSIC list.
> >
> It's now an independent submission to the RFC editor, outside of IETF.
> It was updated based on comments back from the assigned reviewer.
> 
> If you have comments/edits/changes/concerns you'd like to make on the
> altc draft, please email the authors - we'd love to hear them and
> address them.
> 
> -hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 16 Nov 2011 07:55:59 +0000

I think (hope) the RFC Editor actually fixes that stuff, but you're right we should change the draft to correct it now.
I'll ask Mohamed to rev the doc or explicitly point this out to the RFC Editor. (publication was already requested)

-hadriel

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 16 Nov 2011 09:23:01 +0100

Thanks and I would appreciate a quick update to correct the intended status of the draft.

If I remember correctly the draft has some limitations in the way it handles RTCP ports and would for example be incompatible with RFC 3605 because there is no way to indicate a different port for each address type. If you agree would it be possible to state these limitations in the draft.

Regards
Andy

> Sent: 16 November 2011 15:56
> To: Hutton, Andrew
> Cc: Flemming Andreasen; mmusic (E-mail); draft-boucadair-mmusic-
> [email-masked]
> I think (hope) the RFC Editor actually fixes that stuff, but you're
> right we should change the draft to correct it now.
> I'll ask Mohamed to rev the doc or explicitly point this out to the RFC
> Editor. (publication was already requested)
> 
> -hadriel
> 
>