Subject: [MMUSIC] IPv6 transition and ICE

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 09 Apr 2010 15:45:03 +0300

Hi,

as you know, a few IETFs ago, the MMUSIC WG chose to deprecate ANAT and
use ICE for IPv6 transition purposes instead. Since that decision was
made, there have been a few presentations proposing mechanisms that
avoid the use of ICE and have similar properties as ANAT.

In the MMUSIC session in Anaheim, the following two drafts were presented:

   http://tools.ietf.org/html/draft-boucadair-mmusic-altc-00
   http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-01

In the discussions that followed the presentations, people did not seem
to be on the same page when it comes to the requirements leading to
these types of proposals. Therefore, I would like to see discussions on
this list on what requirements people have that ICE cannot meet. Note
that the idea is not to discuss syntax-related issues.

It is important to understand which types of user agents have access to
the networks with these requirements. Do they all have public IP
addresses? Do some of them support ICE? Also, do the requirements relate
to performance (e.g., the delay introduced by connectivity checks) or to
implementation costs?

Something that came up in the discussions and it worthwhile keeping in
mind is that two ICE lite implementations will not use connectivity
checks between them. Also, an ICE lite implementation against a full ICE
implementation simply needs to be able to respond to connectivity
checks. That is, it does not need to implement a full STUN stack.

Thanks,

Gonzalo

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 Apr 2010 12:08:51 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: Friday, April 09, 2010 5:45 AM
> To: mmusic
> Subject: [MMUSIC] IPv6 transition and ICE
> 
> Hi,
> 
> to performance (e.g., the delay introduced by connectivity 
> checks) or to implementation costs?
> 
> checks between them.

"The Web" (read: Google, Microsoft, Yahoo, others) is having issues 
with disconnected IPv6 islands and with poor-quality IPv6 
connections (read: slower than IPv4).  This has resulted in Google
operating a split-zone DNS to only serve AAAA records to DNS servers
that are on Google's whitelist <http://www.google.com/intl/en/ipv6>, 
and has resulted in Yahoo proposing changes to how dual-stack hosts 
send DNS queries 
<http://www.ietf.org/proceedings/10mar/slides/dnsop-7.pdf>.

SIP is routinely used to set up interactive telephone calls, which
are even more time-critical than HTTP.

If two SIP endpoints have IPv6 addresses, and we don't have 
connectivity checks, how will SIP avoid the problems that are
currently being experienced with "The Web"?

-d

> Also, an ICE lite implementation against 
> a full ICE
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Apr 2010 15:21:39 -0400

On 2010-04-14 15:08, Dan Wing wrote:
> that are on Google's whitelist<http://www.google.com/intl/en/ipv6>,

While we're on the topic of the advantages of connectivity checks, they 
are also necessary for punching holes in stateful firewalls whether 
you're on IPv6 or IPv4.

But I think the point of these "we don't need no stinking connectivity 
checks" people is that they are operating in an environment where they 
*know* that they don't need them. They have fully connected IPv4 and 
IPv6 without stateful firewalls nor NATs. And/or they probably use latching.

This doesn't negate the validity of the question: Why is responding to 
connectivity checks (ICE-lite) such a big deal?

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: <[email-masked]>
Date: Thu, 15 Apr 2010 07:44:36 +0200

Dear Simon, 

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Simon Perreault
Envoyé : mercredi 14 avril 2010 21:22
À : [email-masked]
Objet : Re: [MMUSIC] IPv6 transition and ICE

Med: This is not the only way to interact with the FW embedded in the CPE. As an illustration example, once the FQDN of the service contact point (i.e., SBC/P-CSCF) has been resolved and an IPv6 address is retrieved (denoted as IPv6A_SBC), the CPE be configured to accept all incoming SIP messages issued from that IPv6 address (IPv6A_SBC) and to not block them. If not, some push services won't be delivered appropriately. This security policy should be specific to the SIP service which is to be delivered to the SIP UA (identified by IPv6A_UA address) and to not block all incoming SIP messages (since this may lead to experience service trouble to access other SIP-based services subscribed by the customer). A SIP message is granted to be forwarded to the SIP UA, only if it has a source IPv6 address equal to IPv6A_SBC and the destination IPv6 address equal to IPv6A_UA. Otherwise, SIP messages sent to IPv6A_UA are to be discarded by the CPE. As for the RTP streams, the CPE must accept an incoming RTP messages if and only it can be associated with an ongoing RTP session. This is assumes that symmetric RTP is used.

But I think the point of these "we don't need no stinking connectivity 
checks" people is that they are operating in an environment where they 
*know* that they don't need them. 

Med: Yes, furthermore inserting two AF candidate in the SDP is not only between two endpoint UAs but between two P-CSCF/SBC/SBE which are in the same address realm (e.g., service VPN). Implementing connectivity checks overload these nodes.

They have fully connected IPv4 and 
IPv6 without stateful firewalls nor NATs. And/or they probably use latching.

Med: No. 

Med: The question is not this one, but why is it a MUST to support connectivity checks? At least in our case, the SIP UA is embedded in the CPE and optimisation is a must. 

Simon

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: <[email-masked]>
Date: Thu, 15 Apr 2010 07:52:57 +0200

Dear Dan, all,

Please see inline.
Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : mercredi 14 avril 2010 21:09
À : 'mmusic'
Cc : 'Gonzalo Camarillo'
Objet : Re: [MMUSIC] IPv6 transition and ICE

Med: You can use ICE in your case. In our case, we don't need these connectivity checks because we are controlling all the segments: we are providing the CPE which embeds the SIP UA, we have intermediary nodes (SBC/P-CSCF-BGF), there is no NAT in the CPE for messages issued by that SIP UA, IPv6 won't be broken, etc. Furthermore, the use case of the ALTC attribute is not only between two endpoint SIP UAs but may be used between two intermediary service nodes (SBC, P-CSCF) to avoid useless AF translation (to avoid OPEX due to IPv4-IPv6 licensing terms for instance), be able to implement a BGF bypass procedure where both participating BGF are IPv6-enabled (then only one BGF is maintained in the path instead of two), ease the introduction of IPv6-enabled SBC nodes while promoting the use of IPv6 transfer capabilities between these IPv6-enabled SBC without encountering any session failure, etc.

Connectivity checks are not required between two service elements which are in the same addressing realms (VPN), between two SIP UAs embedded in the CPE, etc. 

-d

---

From: <[email-masked]>
Date: Thu, 15 Apr 2010 08:06:21 +0200

Dear Gonzalo,

Thank you for initiating this discussing.

Please see some answers inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Gonzalo Camarillo
Envoyé : vendredi 9 avril 2010 14:45
À : mmusic
Objet : [MMUSIC] IPv6 transition and ICE

Hi,

Med: Some use cases are already elaborated in draft-boucadair-mmusic-altc.

addresses? 

Med: The question is not public IP address but if a NAT exists between the SIP UA and the first service node (e.g., SBC/P-CSCF). One of our deployment schemes is to embed the SIP UA in the CPE: SIP/RTP messages are not translated in the path before being delivered to the first service elements. In some scenarios, the SIP UA is in the LAN, but for this use case, a hosted nat traversal is enforced in the first service elements. With the introduction of IPv6, our plan is to redirect IPv6-enabled UA to an IPv6-enabled service elements (SBC/P-CSCF). For DS-Lite UA, ALTC is not required since we prefer to treat this type of UAs as IPv6-only. Moreover, enclosing alternative AF candidates in SDP is not only between two SIP endpoints but also between two service elements (e.g., SBC, P-CSCF) to encourage the use of IPv6 whenever possible (e.g., ovoid IPv4-IPv6 interworking, optimise OPEX, be able to implement BGF bypass procedure, etc.) while preventing to experience session failures. Connectivity checks are not required in all these use cases.

Do some of them support ICE?

Med: in our case, the answer is No.

 Also, do the requirements relate
to performance (e.g., the delay introduced by connectivity checks) or to
implementation costs?

Med: Optimisation is a must. We should not overload service elements and also CPE with extra operations. As for the implementation, I would invite an implementer to elaborate on this. 

Med: But you still need to answer to connectivity checks, which is not needed in the cases we are handling.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 15 Apr 2010 09:06:12 -0400

On 2010-04-15 01:44, [email-masked] wrote:
> Med: This is not the only way to interact with the FW embedded in the
> CPE. As an illustration example, once the FQDN of the service contact
> point (i.e., SBC/P-CSCF) has been resolved and an IPv6 address is
> retrieved (denoted as IPv6A_SBC), the CPE be configured to accept all
> incoming SIP messages issued from that IPv6 address (IPv6A_SBC) and
> to not block them. If not, some push services won't be delivered
> appropriately. This security policy should be specific to the SIP
> service which is to be delivered to the SIP UA (identified by
> IPv6A_UA address) and to not block all incoming SIP messages (since
> this may lead to experience service trouble to access other SIP-based
> services subscribed by the customer). A SIP message is granted to be
> forwarded to the SIP UA, only if it has a source IPv6 address equal
> to IPv6A_SBC and the destination IPv6 address equal to IPv6A_UA.
> Otherwise, SIP messages sent to IPv6A_UA are to be discarded by the
> CPE. As for the RTP streams, the CPE must accept an incoming RTP
> messages if and only it can be associated with an ongoing RTP
> session. This is assumes that symmetric RTP is used.

Of course, anything is possible when you control the firewall and all 
SIP UAs. You are assuming a very ISP-centric point of view.

This is just one instance of an environment where you *know* you won't 
need connectivity checks.

(But it seems to me that, in this specific case, connectivity checks 
would be of at most equivalent complexity as what you describe. And you 
wouldn't depend on non-standard ALG functionality in the CPE.)

> Med: Yes, furthermore inserting two AF candidate in the SDP is not
> only between two endpoint UAs but between two P-CSCF/SBC/SBE which
> are in the same address realm (e.g., service VPN). Implementing
> connectivity checks overload these nodes.

What do you mean by "overload"? Do you actually mean that processing 
connectivity checks drain system resources?

> At least in our case, the SIP UA is embedded in
> the CPE and optimisation is a must.

I don't understand this. You just described an elaborate ALG for 
bypassing the firewall in the CPE. But if the UA is in the CPE, why 
don't you place it in front of the firewall?

Thanks,
Simon

---

From: <[email-masked]>
Date: Thu, 15 Apr 2010 15:11:28 +0200

Dear Simon,

Please see inline.

Cheers;
Med 

-----Message d'origine-----
De : Simon Perreault [mailto:[email-masked]] 
Envoyé : jeudi 15 avril 2010 15:06
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : Re: [MMUSIC] IPv6 transition and ICE

Med: We don't need any ALG in the CPE since the SIP UA is embedded in the CPE.

Med: Yes.

Med: What is described above is the interaction between the SIP UA module and FW. Both are in the same device.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 15 Apr 2010 09:20:32 -0400

> Med: We don't need any ALG in the CPE since the SIP UA is embedded in the CPE.

Therefore, in this situation the SIP UA has no need for punching holes 
in a firewall since there is no firewall in front of it. I fail to see 
how this use case is relevant to the discussion.

> connectivity checks drain system resources?

This is interesting. Can you explain how? This would be very relevant to 
the discussion.

Thanks,
Simon

---

From: <[email-masked]>
Date: Thu, 15 Apr 2010 15:24:55 +0200

Re-,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Simon Perreault [mailto:[email-masked]] 
Envoyé : jeudi 15 avril 2010 15:21
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : Re: [MMUSIC] IPv6 transition and ICE

Med: Why? This the starting point: we don't need any connectivity checks. As for the performance issues, as I said in a previous message, I would invite Hadriel or Andrew to comment on this. From my service standpoint, all what can reduce the traffic load and processing of involved service nodes is encouraged.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 15 Apr 2010 09:31:49 -0400

On 2010-04-15 09:24, [email-masked] wrote:
> Med: Why? This the starting point: we don't need any connectivity
> checks.

Indeed. What you are describing is one environment among many where 
connectivity checks are not needed. We know these environments exist. 
When one entity controls the endpoints and the network in between, it's 
hardly a surprise that connectivity checks aren't needed.

As an operator, why is it a problem for you to use equipment that would 
implement ICE-lite?

> As for the performance issues, as I said in a previous
> message, I would invite Hadriel or Andrew to comment on this. From my
> service standpoint, all what can reduce the traffic load and
> processing of involved service nodes is encouraged.

I understand, but I was under the impression that the additional traffic 
and processing load would be insignificant. Let's see what others have 
to say about this...

Thanks,
Simon

---

From: <[email-masked]>
Date: Thu, 15 Apr 2010 16:17:26 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Simon Perreault [mailto:[email-masked]] 
Envoyé : jeudi 15 avril 2010 15:32
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : Re: [MMUSIC] IPv6 transition and ICE

Med: The problem is that the ICE-lie/SIP implementation must be able to answer to connectivity checks...this is not the only extra cost, other issues such as randomly generating an ice password, etc. are to be supported.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 15 Apr 2010 10:22:07 -0400

On 2010-04-15 10:17, [email-masked] wrote:
> As an operator, why is it a problem for you to use equipment that
> would implement ICE-lite?
>
> Med: The problem is that the ICE-lie/SIP implementation must be able
> to answer to connectivity checks...this is not the only extra cost,
> other issues such as randomly generating an ice password, etc. are to
> be supported.

Yes, but these are issues for the implementor, not the operator.

Thanks,
Simon

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 15 Apr 2010 08:44:58 -0700

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, April 14, 2010 10:53 PM
> To: Dan Wing; 'mmusic'
> Cc: 'Gonzalo Camarillo'
> Subject: RE: [MMUSIC] IPv6 transition and ICE
> 
> 
> Dear Dan, all,
> 
> Please see inline.
> Cheers,
> Med
> 
>  
> 
> Med: You can use ICE in your case. In our case, we don't need 
> these connectivity checks because we are controlling all the 
> segments: we are providing the CPE which embeds the SIP UA, 
> we have intermediary nodes (SBC/P-CSCF-BGF), there is no NAT 
> in the CPE for messages issued by that SIP UA, IPv6 won't be 
> broken, etc.

If there is no NAT, why not use ICE-Lite?  It doesn't require
sending connectivity checks (only responding to them) and
ICE-Lite only requires walking your local interfaces to
determine your candidate IP addresses (that is, it doesn't
require running STUN to learn the address on the 'far' side
of a NAT).

> Furthermore, the use case of the ALTC attribute 
> is not only between two endpoint SIP UAs but may be used 
> between two intermediary service nodes (SBC, P-CSCF) to avoid 
> useless AF translation (to avoid OPEX due to IPv4-IPv6 
> licensing terms for instance),

So you would prefer IPv4 in cases where IPv6 is available?

> be able to implement a BGF 
> bypass procedure where both participating BGF are 
> IPv6-enabled (then only one BGF is maintained in the path 
> instead of two), ease the introduction of IPv6-enabled SBC 
> nodes while promoting the use of IPv6 transfer capabilities 
> between these IPv6-enabled SBC without encountering any 
> session failure, etc.

How would ICE-Lite fail to meet those 3 requirements.

> Connectivity checks are not required between two service 
> elements which are in the same addressing realms (VPN), 
> between two SIP UAs embedded in the CPE, etc. 

-d

> This message and any attachments (the "message") are 
> confidential and intended solely for the addressees. 
> If you are not the intended addressee of this message, please 
> cancel it immediately and inform the sender.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Apr 2010 20:08:38 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Simon Perreault
> Sent: Thursday, April 15, 2010 9:32 AM
> 

The additional *packets* are insignificant.  Certainly compared to RTP/RTCP it's a nit.  But the processing load is significant.  (although what you may consider "significant" may not be what others do)

For one, these aren't simply "response" packets.  As far as I can tell from reading ICE, and as far as I've seen in traces of the two vendors I've seen which actually implemented ICE drafts, the STUN checks have to use the short-term credential mechanism.  The ICE-Lite server has to perform the STUN short-term credential check of the received request, and digest calc for its response.  EVERY response, to EACH remote UA, using a separate frag/password for each.   Now obviously the server could simply skip verifying the received STUN request, but it still has to do the digest for the response.  That's not free, from a performance perspective.  There's specific hardware which can do this, but it's not free either. 

Now we can debate whether ICE connectivity checks should have really _required_ this or not, but they appear to in practice.  If I'm wrong on that, let me know.

Secondly, even with the slimmed-down logic requirements for a Lite implementation, it appears to require more logic and memory per media session than current systems (SBCs/Gateways/etc.) generally need to use, even for NAT traversal latching.  Whether this has any impact on performance or capacity is vendor specific of course, and I have no idea how much more it is or if it will matter - just that it's more. 

And for what benefit?  For softphones running on people's PC's/laptops behind NATs, across the Internet in a peer-2-peer scenario for free phone calls, ICE makes a lot of sense.  But for the embedded MTA/DSL/Cable-modem market which represents millions of SIP devices and a significant chunk of the current SIP UA market, or for Corporate Enterprise phones, or even for a softphone in your home to your local access service provider... you're not solving a problem for them.  They either don't have a NAT problem, or they've fixed it already without ICE.

Don't get me wrong - I *like* the idea of connectivity checks.  But I want connectivity checks, not SRTP functions cloaked as connectivity checks.  And I have to be able to justify the cost to my customers.  How can I get people to pay more money, to fix a problem they don't have? 

The boucadair draft is trying to *save* providers money, by doing something very simple, for their specific needs - not to spend *more* money on a new mechanism that delays their call setups, increases their SIP signaling load, and that they have to troubleshoot.

-hadriel

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 16 Apr 2010 10:48:59 +0200

I am also of the opinion that the real question is why should we force the implementation of ICE-Lite (i.e. connectivity checks) when it is known not to be needed in a significant number of SIP UA deployment scenarios.

As Hadriel stated connectivity checks don't come for free for a number of reasons and are an added complication we don't necessarily need when deploying dual stack SIP UA's.

For these reasons and due to previous discussions during IETF meetings we proposed an approach based on ICE syntax which is backwards compatible with existing ICE/ICE-Lite implementations in http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-01. 

I still think that we should specify a mechanism for IPV4/6 transition without connectivity checking based on ICE syntax to make it easy to upgrade implementations to ICE-Lite of full ICE on a step by step basis.

Regards
Andy

> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 16 April 2010 01:09
> To: Simon Perreault; [email-masked]
> Cc: [email-masked]
> Subject: Re: [MMUSIC] IPv6 transition and ICE
> 
> 
> 
> [mailto:[email-masked]] On Behalf
> > Of Simon Perreault
> The additional *packets* are insignificant.  Certainly 
> compared to RTP/RTCP it's a nit.  But the processing load is 
> significant.  (although what you may consider "significant" 
> may not be what others do)
> 
> For one, these aren't simply "response" packets.  As far as I 
> can tell from reading ICE, and as far as I've seen in traces 
> of the two vendors I've seen which actually implemented ICE 
> drafts, the STUN checks have to use the short-term credential 
> mechanism.  The ICE-Lite server has to perform the STUN 
> short-term credential check of the received request, and 
> digest calc for its response.  EVERY response, to EACH remote 
> UA, using a separate frag/password for each.   Now obviously 
> the server could simply skip verifying the received STUN 
> request, but it still has to do the digest for the response.  
> That's not free, from a performance perspective.  There's 
> specific hardware which can do this, but it's not free either. 
> 
> Now we can debate whether ICE connectivity checks should have 
> really _required_ this or not, but they appear to in 
> practice.  If I'm wrong on that, let me know.
> 
> Secondly, even with the slimmed-down logic requirements for a 
> Lite implementation, it appears to require more logic and 
> memory per media session than current systems 
> (SBCs/Gateways/etc.) generally need to use, even for NAT 
> traversal latching.  Whether this has any impact on 
> performance or capacity is vendor specific of course, and I 
> have no idea how much more it is or if it will matter - just 
> that it's more. 
> 
> And for what benefit?  For softphones running on people's 
> PC's/laptops behind NATs, across the Internet in a 
> peer-2-peer scenario for free phone calls, ICE makes a lot of 
> sense.  But for the embedded MTA/DSL/Cable-modem market which 
> represents millions of SIP devices and a significant chunk of 
> the current SIP UA market, or for Corporate Enterprise 
> phones, or even for a softphone in your home to your local 
> access service provider... you're not solving a problem for 
> them.  They either don't have a NAT problem, or they've fixed 
> it already without ICE.
> 
> Don't get me wrong - I *like* the idea of connectivity 
> checks.  But I want connectivity checks, not SRTP functions 
> cloaked as connectivity checks.  And I have to be able to 
> justify the cost to my customers.  How can I get people to 
> pay more money, to fix a problem they don't have? 
> 
> The boucadair draft is trying to *save* providers money, by 
> doing something very simple, for their specific needs - not 
> to spend *more* money on a new mechanism that delays their 
> call setups, increases their SIP signaling load, and that 
> they have to troubleshoot.
> 
> -hadriel

---

From: <[email-masked]>
Date: Fri, 16 Apr 2010 14:10:25 +0200

Hi Dan,

Some answers inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : jeudi 15 avril 2010 17:45
À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'mmusic'
Cc : 'Gonzalo Camarillo'
Objet : RE: [MMUSIC] IPv6 transition and ICE

Med: This is not an excluded option, but still even if IPv4 is preferred no connectivity trouble would be experienced (dedicated VC, SIPUA embedded in the CPE, dedicated VPN for sig/media including all P-CSCF/SBC, etc.)

Med: Ice-lite can be used for that also...provided the extra-cost of ice-lite.

-d

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 16 Apr 2010 21:44:09 +0300

Hi,

> Med: But you still need to answer to connectivity checks, which is not needed in the cases we are handling.

but since your network does not have ICE nodes, you will not need to
answer any connectivity checks... or are you concerned with the fact
that you would need to implement the code able to respond connectivity
checks even if it would never be executed?

Thanks for the clarification,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 16 Apr 2010 21:41:05 +0300

Hi,

> Med: Ice-lite can be used for that also...provided the extra-cost of

What type of cost do you have in mind?

If all the nodes in your network are ICE lite, you will never exchange
connectivity checks. Therefore, the cost of running you network would be
the same as if you were using something like ANAT, right?

If you are thinking of implementation costs, your ICE lite
implementation (simply in order to be able to call itself ICE lite)
would need to be able to respond to connectivity checks (even if in your
network you would never use them). Note that implementing this
capability is  easier and cheaper than implementing a fully-featured
STUN stack.

Given that in a network like the one you have described nodes will only
face ICE lite implementation, some people have suggested that all nodes
can claim to be ICE lite without even being able to respond to
connectivity check. Note that this would not be compliant with the ICE
spec and could cause interopeability problem if one of those "fake" ICE
lite nodes ever got deployed in a network with ICE nodes.

Cheers,

Gonzalo

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Apr 2010 15:55:54 -0400

> Of Gonzalo Camarillo
> Sent: Friday, April 16, 2010 2:41 PM
> 

Under that type of argument, there should be no problem assigning a separate SDP attribute for an alternate connection addr:port.  After all, it's only going to devices which are "in the club".  And that way we won't need to break an existing RFC (ICE).

But that's not the case really - the operators control the vendor/model/version of their servers, and most of the clients, but they like the ability to offer service to different clients, including softphones.  And they don't often control the IP-PBX in an Enterprise that has a sip-trunk to them.  Pretending to do ICE-Lite, without actually doing ICE-Lite, will cause an interop issue for any future device that can do ICE-Full.  I don't think that's a good thing.

-hadriel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 16 Apr 2010 23:31:13 +0300

Hi Hadriel,

just in case it was not clear from my email, I also think that is not a
good thing at all.

Cheers,

Gonzalo

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 19 Apr 2010 12:02:03 +0200

Hi,

Pretending to be ICE-Lite when your not does not sound like something we should be talking about to me.

I again agree with Hadriel on this one whilst in many deployments the network components may be controlled the deployment is an open system in terms of the endpoints and applications which can be deployed to build the solution. 

Therefore whilst a SIP based solution may be deployed in the knowledge that connectivity checking is unnecessary we still may encounter dual stack SIP UA's which support ICE, ICE-Lite, or ICE-microLite within the deployment. Whilst ICE-microLite is backwards compatible with the full ICE client it will fallback to the default address (I.e. IPv4) if the full ICE Client does not understand ICE-microLite and for this reason we want to standardise the ICE-microLite extensions.

The extra cost of ICE-Lite is of course implementing and making sure all necessary components in a deployment support and have the capacity to support the unnecessary connectivity checks. It would I think be better to concentrate on making sure IPv6 get deployed and not waste valuable cycles on things we don't need at this time.

However ICE/ICE-Lite is the agreed generic solution which is why we specified an approach based on ICE syntax which provides a clear path to supporting ICE/ICE-Lite.

I don't support taking this outside of the IETF and don't understand the argument against ICE-microLite. The main objection I have heard is that it does not cost much to implement connectivity checks but that is of course subjective and dependant on many things.

Regards
Andy

> Sent: 16 April 2010 20:56
> To: Gonzalo Camarillo; [email-masked]
> Cc: 'mmusic'; Dan Wing
> Under that type of argument, there should be no problem 
> assigning a separate SDP attribute for an alternate 
> connection addr:port.  After all, it's only going to devices 
> which are "in the club".  And that way we won't need to break 
> an existing RFC (ICE).
> 
> But that's not the case really - the operators control the 
> vendor/model/version of their servers, and most of the 
> clients, but they like the ability to offer service to 
> different clients, including softphones.  And they don't 
> often control the IP-PBX in an Enterprise that has a 
> sip-trunk to them.  Pretending to do ICE-Lite, without 
> actually doing ICE-Lite, will cause an interop issue for any 
> future device that can do ICE-Full.  I don't think that's a 
> good thing.
> 
> -hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Apr 2010 10:00:38 -0700

> Sent: Thursday, April 15, 2010 5:09 PM

So, if connectivity checks that didn't require HMAC-SHA1
but instead did something simplier (let's call it CRC32
for now), you would find them valuable?

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Apr 2010 10:01:46 -0700

> [mailto:[email-masked]] On Behalf Of Hutton, Andrew
> Sent: Friday, April 16, 2010 1:49 AM
> To: Hadriel Kaplan; Simon Perreault; 
> [email-masked]; [email-masked]
> I am also of the opinion that the real question is why should 
> we force the implementation of ICE-Lite (i.e. connectivity 
> checks) when it is known not to be needed in a significant 
> number of SIP UA deployment scenarios.
> 
> As Hadriel stated connectivity checks don't come for free for 
> a number of reasons and are an added complication we don't 
> necessarily need when deploying dual stack SIP UA's.
> 
> For these reasons and due to previous discussions during IETF 
> meetings we proposed an approach based on ICE syntax which is 
> backwards compatible with existing ICE/ICE-Lite 
> implementations in 
> http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-01. 

I like that idea.

(I would still like to understand Hadriel's concern with SHA1
processing, though.)

-d

> I still think that we should specify a mechanism for IPV4/6 
> transition without connectivity checking based on ICE syntax 
> to make it easy to upgrade implementations to ICE-Lite of 
> full ICE on a step by step basis.
> 
> Regards
> Andy
> 
>  
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Apr 2010 15:42:45 -0400

> From: Dan Wing [mailto:[email-masked]]
> Sent: Tuesday, April 20, 2010 1:01 PM
> To: Hadriel Kaplan; 'Simon Perreault'; mohamed.boucadair@orange-
> ftgroup.com
> 

I personally would find simple connectivity checks valuable - but I don't know that my customers would.  I think some would, but some feel it doesn't matter.  And in their defense, we're not talking about very many hops in between, so the odds are incredibly high that if SIP worked to begin with, RTP will too. 

I was thinking about suggesting a non-digest connectivity check, but given the syntax of ICE's attributes and rules, I don't see a way to do that in a backwards-compatible manner really other than through separate non-ICE attributes.

-hadriel

---

From: Simon Perreault <[email-masked]>
Date: Tue, 20 Apr 2010 15:46:09 -0400

On 2010-04-20 15:42, Hadriel Kaplan wrote:
>> So, if connectivity checks that didn't require HMAC-SHA1 but
>> instead did something simplier (let's call it CRC32 for now), you
>> would find them valuable?
>
> I personally would find simple connectivity checks valuable - but I
> don't know that my customers would.  I think some would, but some
> feel it doesn't matter.  And in their defense, we're not talking
> about very many hops in between, so the odds are incredibly high that
> if SIP worked to begin with, RTP will too.

But the computing complexity of answering connectivity checks doesn't 
really matter in the ICE-microlite use-case since connectivity checks 
are not sent anyway, right?

It would rather be about implementation complexity, right?

Simon

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Apr 2010 16:28:14 -0400

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Tuesday, April 20, 2010 3:46 PM
> To: Hadriel Kaplan
> 

Sure, ICE-microlite is not ICE at all, so there are no connectivity checks.
But I think Dan was talking about connectivity checks.

-hadriel

---

From: Simon Perreault <[email-masked]>
Date: Tue, 20 Apr 2010 16:36:38 -0400

> But I think Dan was talking about connectivity checks.

Let me rephrase my question...

You mentioned earlier that one reason you didn't like ICE-lite and you 
were proposing ICE-microlite instead was that connectivity checks caused 
too much load on the CPU.

Now, if you were to use ICE-lite instead of ICE-microlite, there would 
still be no connectivity checks, so the CPU load wouldn't happen anyway.

And so my question is: since CPU load is not an issue either for 
ICE-lite or ICE-microlite, why is ICE-microlite better? Is it because 
it's easier to code?

Thanks,
Simon

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Apr 2010 17:15:49 -0400

> Sent: Tuesday, April 20, 2010 4:37 PM
> To: Hadriel Kaplan
> 

Ahh, no - the reason we don't want to use ICE-Lite is if the offer goes to an ICE-full-capable endpoint, then since we offered ICE-Lite the endpoint would expect to do connectivity checks and it can't really.  In other words, we'd be lying about being an ICE-Lite UA.

-hadriel
p.s. I'm not proposing ICE-microlite, but rather draft-boucadair-mmusic-altc-00, but the difference doesn't matter much in this regard (it matters for other reasons).

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Apr 2010 14:40:10 -0700

> p.s. I'm not proposing ICE-microlite, but rather 
> draft-boucadair-mmusic-altc-00, but the difference doesn't 
> matter much in this regard (it matters for other reasons).

When we do talk about those Other Reasons (which I agree we should), can we
put draft-ietf-mmusic-sdp-capability-negotiation on the table for a way to do
IPv6?  It doesn't do connectivity checks, either.

-d

---

From: Simon Perreault <[email-masked]>
Date: Tue, 20 Apr 2010 17:58:11 -0400

> IPv6?  It doesn't do connectivity checks, either.

And at that time I would also like to be reminded why ANAT doesn't fit
the bill.

Thanks,
Simon

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Apr 2010 15:09:02 -0700

> And at that time I would also like to be reminded why ANAT doesn't fit

Sure.  

But here is a justification in email:

ANAT (RFC4091) is not backwards-compatible with endpoints that
don't know ANAT.  Which is why ICE, 
draft-ietf-mmusic-sdp-media-capabilities, 
draft-boucadair-mmusic-altc, and draft-hutton-mmusic-icemicrolite
are all using "a=" rather than putting things optional transports
on "m=" lines.

An example of ANAT's problem, using the example from RFC4091 as an Offer:

      v=0
      o=bob 280744730 28977631 IN IP4 host.example.com
      s=
      t=0 0
      a=group:ANAT 1 2
      m=audio 25000 RTP/AVP 0
      c=IN IP6 2001:DB8::1
      a= <ICE-encoded additional IPv6 addresses (and ports)>
      a=mid:1
      m=audio 22334 RTP/AVP 0
      c=IN IP4 192.0.2.1
      a= <ICE-encoded additional IPv4 addresses (and ports)>
      a=mid:2

Per SDP processing rules, a device that doesn't understand ANAT 
would ignore the "a=" lines it doesn't understand and would 
process the following, which means there are two audio streams
(one on IPv6 the other on IPv4) when we really wanted to signal
"choose one":

      v=0
      o=bob 280744730 28977631 IN IP4 host.example.com
      s=
      t=0 0
      m=audio 25000 RTP/AVP 0
      c=IN IP6 2001:DB8::1
      m=audio 22334 RTP/AVP 0
      c=IN IP4 192.0.2.1

Also, if the UDP ports are the same (as would commonly occur 
with a dual-stack host, and as would occur with stateless
NAT64), the meaning of the same UDP ports is undefined
which is why Section 7.5.3 of RFC3388 prohibits that.

-d

---

From: Muthu Arul <[email-masked]>
Date: Wed, 21 Apr 2010 08:23:03 +0530

This is why we have RFC 4092. An ANAT offerer would typically use the
sdp-anat option tag in a Require header, giving no choice to the answerer to
misinterpret the offer. Of course, it breaks backward compatibility.

Muthu

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Apr 2010 00:39:47 -0400

Right, so 4092 is totally useless in practice.
-hadriel

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Muthu Arul
Sent: Tuesday, April 20, 2010 10:53 PM
To: Dan Wing
Cc: [email-masked]
Subject: Re: [MMUSIC] IPv6 transition and ICE

This is why we have RFC 4092. An ANAT offerer would typically use the sdp-anat option tag in a Require header, giving no choice to the answerer to misinterpret the offer. Of course, it breaks backward compatibility.

Muthu
Sure.

     v=0
     o=bob 280744730 28977631 IN IP4 host.example.com<http://host.example.com>
     s=
     t=0 0
     a=group:ANAT 1 2
     m=audio 25000 RTP/AVP 0
     c=IN IP6 2001:DB8::1
     a= <ICE-encoded additional IPv6 addresses (and ports)>
     a=mid:1
     m=audio 22334 RTP/AVP 0
     c=IN IP4 192.0.2.1
     a= <ICE-encoded additional IPv4 addresses (and ports)>
     a=mid:2

     v=0
     o=bob 280744730 28977631 IN IP4 host.example.com<http://host.example.com>
     s=
     t=0 0
     m=audio 25000 RTP/AVP 0
     c=IN IP6 2001:DB8::1
     m=audio 22334 RTP/AVP 0
     c=IN IP4 192.0.2.1

-d

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 20 Apr 2010 22:15:52 -0700

> From: Muthu Arul [mailto:[email-masked]] 
> Sent: Tuesday, April 20, 2010 7:53 PM
> To: Dan Wing
> Cc: Simon Perreault; [email-masked]
> This is why we have RFC 4092. An ANAT offerer would typically 
> use the sdp-anat option tag in a Require header, giving no 
> choice to the answerer to misinterpret the offer. Of course, 
> it breaks backward compatibility.

And would fail with SIP forking if any of the forked endpoints
doesn't support the Option Tag.

-d

---

From: Muthu Arul <[email-masked]>
Date: Wed, 21 Apr 2010 10:57:48 +0530

Yes, the only use-case for ANAT is a very controlled environment. No wonder
why US DoD chose to use it..

Muthu

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 21 Apr 2010 10:15:47 +0200

Hadriel is correct the reason we need ICE-microLite is that if we use ICE syntax, which is the IETF recommended transition mechanism, and the offer reaches a full ICE client then it will expect the offerer to support connectivity checking.

This means that we would have to make sure all dual stack entities in the network support and are provisioned for connectivity checking from day one of a dual stack deployment, even though we know that in many SIP deployments we don't really need connectivity checking. The result is unnecessary delays in deploying dual stack devices.

ICE-microLite allows for a more step by step approach in which we can use ICE syntax for negotiating the IP address family without the delays and expense caused by having to make sure everything supports and is provisioned for connectivity checking. However given that the syntax is compatible with ICE/ICE-Lite then the implementation can easily make the step up to this if required to do so.

Regards
Andy

> Sent: 20 April 2010 22:16
> To: Simon Perreault
> Cc: [email-masked]; Dan Wing
> Ahh, no - the reason we don't want to use ICE-Lite is if the 
> offer goes to an ICE-full-capable endpoint, then since we 
> offered ICE-Lite the endpoint would expect to do connectivity 
> checks and it can't really.  In other words, we'd be lying 
> about being an ICE-Lite UA.
> 
> -hadriel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 21 Apr 2010 16:17:27 +0300

Hi,

let me try to summarize where we are in this conversation because I
still think people do not have a clear view on what the requirements
are. It has been claimed that in the deployment scenarios we are talking
about, there will never be a full ICE implementation. Therefore, if all
the nodes are ICE lite, you will never ever see a connectivity check in
the network.

Of course, for your nodes to be able to claim they are ICE lite, they
have to be able to respond to connectivity checks. There is an
implementation cost there (relatively small, though, since you do not
even need to implement a full STUN stack), but there is no performance
penalty at all because that code will never be run in your network.

So, the tradeoff seems to be between the following two options:

1) you implement the ability to respond to connectivity checks so that
you are ICE lite compliant. In your environment, you will never see a
connectivity check. However, your implementation will be ready to be
deployed in a different environment if needed (i.e., you get code
reusability).

2) you do not implement the ability to respond to connectivity checks.
You are not ICE lite compliant but implement something similar to ANAT
but using a single m line (the syntax is not important for this
discussion). In your environment, everything works exactly the same as
in the case where every node was ICE lite (i.e., no connectivity checks
in the network). However, if your implementation is deployed in a
different environment, things may not work.

As it has been pointed out, from the operator's perspective, there is no
difference between 1) and 2). The difference only affects the vendor.

Is this a fair description of the tradeoff we are talking about? It it
is, let's analyze it. If it's not, what is missing?

Thanks,

Gonzalo

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Apr 2010 10:11:08 -0400

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Wednesday, April 21, 2010 9:17 AM
> To: Hadriel Kaplan
> 

No, there may be endpoints which do full ICE - maybe not now, but someday it's certainly possible.  I've seen a draft version of ICE implemented in SIP endpoints, although the big users of ICE today appear to be non-SIP applications (ironically).

> [snipped text]

Sure, and if you deploy ICE in a different environment things may not work either.  There are known cases in which ICE will not work, due to middleboxes and network operator policies.  

Let's not fool ourselves - ICE isn't the historically common baseline upon which everything has been deployed and proven - it's the new kid in town. 

-hadriel

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 21 Apr 2010 11:36:48 -0400

Dan Wing writes:
> When we do talk about those Other Reasons (which I agree we should),
> can we put draft-ietf-mmusic-sdp-capability-negotiation on the table
> for a way to do IPv6?  It doesn't do connectivity checks, either.

Relatedly, I think it would be a good idea if whatever solution we come to should encompass the use cases driving the ccap support in draft-garcia-mmusic-sdp-misc-cap-01, i.e. offering an alternative between IP and circuit-switched bearer connections.

My suggestion at the microphone in the WG meeting (using ICE for circuit-switched connections) was, I know, fairly outrageous.  However, I think it's important that mechanisms work together reasonably.  For instance, a use case where someone wants to offer a three-way choice between a v4, a v6, and a CS address seems fairly likely, and it seems like it'd be better if this were not entirely unlike the way you'd offer just the two-way choice between v4 and v6.

This is not to say that whatever mechanism is decided upon necessarily has to have CapNeg-per-se as an intrinsic part of it.

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 21 Apr 2010 08:56:43 -0700

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Wednesday, April 21, 2010 7:11 AM
> To: Gonzalo Camarillo
> Cc: Simon Perreault; [email-masked]; Dan Wing
> No, there may be endpoints which do full ICE - maybe not now, 
> but someday it's certainly possible.  I've seen a draft 
> version of ICE implemented in SIP endpoints, although the big 
> users of ICE today appear to be non-SIP applications (ironically).

Yahoo and MSN implement ICE, and both do SIP.  MSN's SIP is sent
inside of some sort of XML wrapper.  Both are unencrypted and can 
easily be seen with tcpdump or Wireshark.

> Sure, and if you deploy ICE in a different environment things 
> may not work either.  There are known cases in which ICE will 
> not work, due to middleboxes and network operator policies.  
> 
> Let's not fool ourselves - ICE isn't the historically common 
> baseline upon which everything has been deployed and proven - 
> it's the new kid in town. 

IPv6 is new, too, and so is MMUSIC and SIP's attempts to
get a backwards-compatible IPv4/IPv6 mechanism that works.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 21 Apr 2010 08:56:46 -0700

> Sent: Wednesday, April 21, 2010 6:17 AM
> To: Hadriel Kaplan
> Is this a fair description of the tradeoff we are talking about?

Yes.

-d

> It it
> > Ahh, no - the reason we don't want to use ICE-Lite is if 
> the offer goes to an ICE-full-capable endpoint, then since we

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Apr 2010 12:07:03 -0400

> From: Hutton, Andrew [mailto:[email-masked]]
> Sent: Wednesday, April 21, 2010 4:16 AM
> To: Hadriel Kaplan; Simon Perreault
> 
> ICE-microLite allows for a more step by step approach in which we can use
> ICE syntax for negotiating the IP address family without the delays and
> expense caused by having to make sure everything supports and is
> provisioned for connectivity checking. However given that the syntax is
> compatible with ICE/ICE-Lite then the implementation can easily make the
> step up to this if required to do so.

This topic is tangential to whether we have to use ICE to offer two address families... but I really think re-using the ICE syntax for not-ICE as currently done in the microlite-draft is confusing and misleading.  

In particular, the ICE-microlite draft currently sets the candidate port values to 0 and then relies on a mismatch between the m= line and the candidate lines in order to prevent ICE-full peers from using ICE when they receive a microlite offer.  But it then makes the rest of the SDP look like ICE, when it's *not* ICE.

If you're going to go down that path, then why even encode a "special" ice-pwd and ice-ufrag?  Don't include them in the SDP at all, because you don't need them and that will provide more of a guarantee that a full-ICE device does not do ICE when getting the SDP.  Likewise for the a=ice-lite attribute.  It's not really ice-lite, so don't have the SDP pretend it is.

What this is *really* is a new type of candidate line, so it should be a new candidate-type field value.  I.e., not a "host" or "srflx", but rather "static" or some such.  

In short, instead of doing this:
  c=IN IP4 192.0.2.2
  a=ice-lite
  a=ice-options microlite
  a=ice-pwd:microlitemicrolitemicrolite
  a=ice-ufrag:microlite
  m=audio 3480 RTP/AVP 0
  a=candidate:1 1 UDP 2130706431 2001:::1 0 typ host microliteport 3478
  a=candidate:2 1 UDP 2130706430 192.0.2.2 0 typ host microliteport 3480

Do this:
  c=IN IP4 192.0.2.2
  a=ice-options microlite
  m=audio 3480 RTP/AVP 0
  a=candidate:1 1 UDP 2130706431 2001:::1 0 typ static mport 3478
  a=candidate:2 1 UDP 2130706430 192.0.2.2 0 typ static mport 3480

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Apr 2010 12:19:36 -0400

> Sent: Wednesday, April 21, 2010 11:57 AM
> 

And yet they both don't rely on it/use it for calls to the PSTN or peer providers.  Hmmm... I wonder why?  Maybe because they don't want to pay for that cost burden when they don't need to?

But I was thinking more of Google's XMPP and MSoft's Communicator (which is arguably not "SIP").

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 21 Apr 2010 09:33:39 -0700

> And yet they both don't rely on it/use it for calls to the 
> PSTN or peer providers.  Hmmm... I wonder why?  Maybe because 
> they don't want to pay for that cost burden when they don't need to?

No NATs in that path.  No need to optimize in-home PC-to-PC 
communication to stay inside the home.

Seems we would still want those optimizations with IPv6 and
devices in the home -- unless we have a way to achieve those
in a standard way without ICE?

> But I was thinking more of Google's XMPP and MSoft's 
> Communicator (which is arguably not "SIP").

Yes, I expected those were the non-SIP things you were thinking
about.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Apr 2010 12:47:21 -0400

> Sent: Wednesday, April 21, 2010 12:34 PM
> To: Hadriel Kaplan; 'Gonzalo Camarillo'
> >

Well, I know you know that releasing the media to go direct when the UA's are behind the same NAT is a capability supported by devices-which-shall-not-be-named.  But no it's not "standard" because it didn't require a standard, because there was no new signaling to interop (I know it's evil not to require more standards).  

And yes in some hypothetical two-level NAT case it's possible that such schemes won't work, though they sure seem to work all the time in practice.  And before you say it, yes I expect proliferation of CGNs to make it a real problem. (well... a problem for those who don't own the CGNs :)

But the proposals on the table aren't suggesting we deprecate ICE, or to not use ICE when it's appropriate.  All they're saying is that for the non-PC-to-PC case, they don't need or want ICE.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 21 Apr 2010 10:23:23 -0700

> Well, I know you know that releasing the media to go direct 
> when the UA's are behind the same NAT is a capability 
> supported by devices-which-shall-not-be-named.  But no it's 
> not "standard" because it didn't require a standard, because 
> there was no new signaling to interop (I know it's evil not 
> to require more standards).  
>
> And yes in some hypothetical two-level NAT case it's possible 
> that such schemes won't work, though they sure seem to work 
> all the time in practice.  And before you say it, yes I 
> expect proliferation of CGNs to make it a real problem. 
> (well... a problem for those who don't own the CGNs :)

Yes, that was exactly what I was going to point out.

> But the proposals on the table aren't suggesting we deprecate 
> ICE, or to not use ICE when it's appropriate.  All they're 
> saying is that for the non-PC-to-PC case, they don't need or want ICE.

Ok.

-d

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Apr 2010 19:50:26 +0200

> [mailto:[email-masked]] On Behalf Of Dan Wing
> Sent: 21 April 2010 16:57
> To: 'Gonzalo Camarillo'; 'Hadriel Kaplan'
> Cc: [email-masked]
[JRE] Except that Gonzalo's original assumption, that all nodes support ICE-lite, is incorrect. As soon as you place a full ICE implementation into a network that does not need full ICE, the ICE-lite nodes are required to respond to connectivity checks.

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Apr 2010 19:54:08 +0200

> Sent: 21 April 2010 17:07
> To: Hutton, Andrew; Simon Perreault
> This topic is tangential to whether we have to use ICE to 
> offer two address families... but I really think re-using the 
> ICE syntax for not-ICE as currently done in the 
> microlite-draft is confusing and misleading.  
> 
> In particular, the ICE-microlite draft currently sets the 
> candidate port values to 0 and then relies on a mismatch 
> between the m= line and the candidate lines in order to 
> prevent ICE-full peers from using ICE when they receive a 
> microlite offer.  But it then makes the rest of the SDP look 
> like ICE, when it's *not* ICE.
> 
> If you're going to go down that path, then why even encode a 
> "special" ice-pwd and ice-ufrag?  Don't include them in the 
> SDP at all, because you don't need them and that will provide 
> more of a guarantee that a full-ICE device does not do ICE 
> when getting the SDP.  Likewise for the a=ice-lite attribute. 
>  It's not really ice-lite, so don't have the SDP pretend it is.
> 
> What this is *really* is a new type of candidate line, so it 
> should be a new candidate-type field value.  I.e., not a 
> "host" or "srflx", but rather "static" or some such.  
> 
[JRE] Yes, the details can be fixed once we agree the principle. The idea of microlite is to reuse as much of the ICE syntax as possible, but in a way that will behave predictably when interworking with full-ICE or ICE-lite implementations.

John

---

From: <[email-masked]>
Date: Wed, 21 Apr 2010 20:01:16 +0200

Dear Hadriel, all,

Fully agreed.

Cheers,
Med
________________________________________
De : [email-masked] [[email-masked]] de la part de Hadriel Kaplan [[email-masked]]
Date d'envoi : mercredi 21 avril 2010 18:47
À : Dan Wing; 'Gonzalo Camarillo'
Cc : [email-masked]
Objet : Re: [MMUSIC] IPv6 transition and ICE

-hadriel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 22 Apr 2010 10:19:06 +0300

Hi,

Gonzalo wrote:
>> It has been claimed that in the deployment scenarios we are
>> talking about, there will never be a full ICE implementation.

Hadriel responded:
> No, there may be endpoints which do full ICE - maybe not now, but
> someday it's certainly possible.

Help me understand the environments we are talking about. It has been
claimed that in the environments people had in mind, all user agents
were under the control of the operator. Therefore, the operator could
make sure they never used full ICE by, for example, making them behave
as ICE lite or using any other mechanism.

Now you are saying that in those environments, you may actually have
full ICE user agents. But if that is the case, even if we standardize a
new mechanism, when two of those full ICE user agents try to talk to
each other, they will use full ICE... or will those environments force
every call to go through an SBC so that two user agents can never talk
to each other directly?

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 22 Apr 2010 10:26:14 +0300

Hi John,

> [JRE] Except that Gonzalo's original assumption, that all nodes
> support ICE-lite, is incorrect. As soon as you place a full ICE
> implementation into a network that does not need full ICE, the
> ICE-lite nodes are required to respond to connectivity checks.

That was not really an assumption. It was what Mohamed had said in this
thread earlier: that in their networks, no user agent would support full
ICE. As you point out, it seems other people have the requirement to
support full-ICE user agents as well. I just sent a note asking for
clarifications on how exactly the environments we want to tackle look
like so that we have a common understanding of what we are trying to
resolve here.

Thanks,

Gonzalo

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 22 Apr 2010 13:04:45 +0200

See below.

Regards
Andy

> Sent: 22 April 2010 08:19
> To: Hadriel Kaplan

The environment I have in mind is an open system therefore any SIP UA can be deployed including UA's suppporting full ICE. We don't want to restrict customers to only deploying ICE-Lite UA's.

> every call to go through an SBC so that two user agents can never talk

I am quite happy for two full ICE agents to use full ICE. What I am not happy about is forcing all dual stack SIP UA's to support at least ICE-Lite including connectivity checking just because they might have to interwork with a full ICE SIP UA when we know that in a particular deployment connectivity checks are not required.

If we standardise ICE-microLite then we lower the bar for deploying dual stack SIP UA's and provides a step by step approach to introducing ICE-Lite and full ICE clients. If an ICE-microLite client encounters an ICE implementation that does not support the microLite option then the worst that happens is they have to fallback to using the default connection address.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 22 Apr 2010 08:30:03 -0400

On 2010-04-22 07:04, Hutton, Andrew wrote:
> The environment I have in mind is an open system therefore any SIP UA
> can be deployed including UA's suppporting full ICE. We don't want to
> restrict customers to only deploying ICE-Lite UA's.

Follow-up question:

In this environment, would the full ICE clients *need* full ICE, or 
would they just have it implemented in them but not actually need 
connectivity checks?

If they don't actually *need* it, then why not just turn full ICE off 
and let them behave as ICE-lite? After all, any full ICE implementation 
also implements ICE-lite, and it would be just a matter of configuring 
it to behave like ICE-lite.

If they *do* need it, then how will they work when the remote system 
doesn't answer connectivity checks?

Thanks,
Simon

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 22 Apr 2010 17:24:01 +0200

See below. 

> [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: 22 April 2010 13:30
> To: [email-masked]

If they are full ICE they will have implemented the ICE spec so will have it implemented.

> it to behave like ICE-lite.

I would not like to guarantee that all full ICE clients can be configured to behave like ICE-Lite clients I don't think ICE mandates this and even if it did I would prefer not to rely on them being configured in this way.

> doesn't answer connectivity checks?

They don't need it and they should not expect the remote system to respond which is why we have written the ICE-microLite draft.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Apr 2010 11:33:57 -0400

> Sent: Thursday, April 22, 2010 3:19 AM
> 

No, not really - the operators do control a lot of the user agents, and in most cases today they do control _all_ of them typically; but many of them want to be able to support any UA, even soft-clients running on your PC.

I don't think anyone said they would make sure ICE-full would be disabled - we meant the operators control the network, and have no problem which needs ICE or ICE-Lite to solve, but do have a desire to offer both IPv4 and IPV6 address families.

> each other, they will use full ICE... 

That's fine.  There's no issue/concern/change with letting two ICE-full agents do full ICE between each other, in any environment.  Neither of the proposals for alternate addresses were suggesting that ICE-full would be disabled or blocked.  We're just saying ICE-Lite ain't so Lite, and for publicly addressed servers in these environments there's neither a need nor cost-justification for even ICE-Lite.

-hadriel

---

From: Simon Perreault <[email-masked]>
Date: Thu, 22 Apr 2010 11:37:34 -0400

On 2010-04-22 11:33, Hadriel Kaplan wrote:
> even soft-clients running on your PC.

Now I'm confused. Wouldn't they need ICE-lite on their servers in order 
to support that?

...or do they really control *all* the network, including my PC? ;)

Simon

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Apr 2010 11:51:20 -0400

> Sent: Thursday, April 22, 2010 11:38 AM
> To: Hadriel Kaplan
> Cc: Gonzalo Camarillo; [email-masked]; Dan Wing

No, the whole point here is to let those servers not have to do ICE-Lite.  In others words, when your PC sends/receives a call to/from their servers, your PC would either also do/understand this new thing "ICE-ultralight", or it wouldn't and would revert to just normal SIP behavior.  But when it makes a call to another PC, it can do ICE-Full if that other PC does ICE.

-hadriel

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 22 Apr 2010 09:21:09 -0700

On 04/22/2010 08:51 AM, Hadriel Kaplan wrote:
> 
> 
>> -----Original Message----- From: Simon Perreault
>> [mailto:[email-masked]] Sent: Thursday, April 22, 2010 11:38
>> AM To: Hadriel Kaplan Cc: Gonzalo Camarillo; [email-masked]; Dan Wing 
>> Now I'm confused. Wouldn't they need ICE-lite on their servers in order to
>> support that?
> 
> No, the whole point here is to let those servers not have to do ICE-Lite.  In
> others words, when your PC sends/receives a call to/from their servers, your
> PC would either also do/understand this new thing "ICE-ultralight", or it
> wouldn't and would revert to just normal SIP behavior.  But when it makes a
> call to another PC, it can do ICE-Full if that other PC does ICE.

The reason an endpoint that is connected on the Internet needs to implement
ICE-lite is to help other endpoints that are deployed behind a NAT.  By
insisting to remove this feature, you are basically telling all this endpoints
that they cannot use ICE and that they need to find another way to solve their
problems when connecting to this endpoints (like more SBCs?).

ICE-lite should be seen as the (very small) price to pay to be a decent citizen
of the Internet.

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 Apr 2010 09:27:47 -0700

> [mailto:[email-masked]] On Behalf Of Marc Petit-Huguenin
> Sent: Thursday, April 22, 2010 9:21 AM
> To: Hadriel Kaplan
> Cc: Gonzalo Camarillo; Dan Wing; [email-masked]
> ICE-lite should be seen as the (very small) price to pay to 
> be a decent citizen of the Internet.

Agreed.

But the networks being discussed here are not "The Internet".

Rather, they are closed networks where the network operator has
ensured (a) there are no NATs, or (b) the SIP signaling
is unencrypted the NATs have SIP ALGs, or (c) there are
SBCs that do media latching.

-d

---

From: Emil Ivov <[email-masked]>
Date: Thu, 22 Apr 2010 18:37:13 +0200

> But the networks being discussed here are not "The Internet".

Then why are we discussing them here?

Emil

-- 
Emil Ivov, Ph.D.                               67000 Strasbourg,
Project Lead                                   France
SIP Communicator
[email-masked]                     PHONE: +33.1.77.62.43.30
http://sip-communicator.org                    FAX:   +33.1.77.62.47.31

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 22 Apr 2010 09:39:10 -0700

> SBCs that do media latching.

I am confused - if there is no interoperability issues with Internet endpoints,
why are we having this discussion?  Can't this people solve their problems by
just sending a memo to themselves saying that they will not use ICE-lite?

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 Apr 2010 09:41:28 -0700

> Then why are we discussing them here?

A good question.

But there are non-Internet protocols that the IETF does 
standardize -- DHCP and ARP are good examples of protocols
that don't run 'on the Internet'.  And private addresses
[RFC1918].

Here is a thought:  if these are devices that aren't On The 
Internet, they should just stick with the soon-to-be-Historic 
ANAT (RFC4091), because all of the devices are Controlled by 
The Service Provider.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 Apr 2010 09:43:46 -0700

> just sending a memo to themselves saying that they will not 

Yep.

Or do anything else they want in the closed world of their
own network.

I believe what's being asked is for MMUSIC to help decide
what should be done in such a closed network -- what would
be best.  The concern I see raised on the mailing list is
"what happens when devices on that closed network talk
on the Internet".  Because, in many people's experience,
that happens after a few years.  But that concern is shot
down because "it is a closed network".

-d

---

From: Simon Perreault <[email-masked]>
Date: Thu, 22 Apr 2010 12:56:43 -0400

> ANAT (RFC4091), because all of the devices are Controlled by

My thoughts, precisely.

Simon

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Apr 2010 13:09:10 -0400

> From: Marc Petit-Huguenin [mailto:[email-masked]]
> Sent: Thursday, April 22, 2010 12:21 PM
> 
> 

No, we are not "insisting to remove this feature" at all.  We are not asking to deprecate ICE, we are not suggesting endpoints should not implement ICE, and we are not suggesting they cannot use ICE.  Every proposal thus far has assumed that an endpoint which supports ICE would make an ICE offer.  It MAY also indicate additional capabilities in that offer (whatever those would be), but absolutely no one has suggested it would not also be able to use ICE if it ends up talking with another ICE-capable device.

All we're saying is that for a fairly common case in practice, ICE is not necessary and is cost-prohibitive and is thus not going to be implemented in some devices.  The problem we're trying to solve is the ability to offer both an IPv4 and IPv6 address, for these common cases.  Personally I think of this as completely orthogonal to ICE, but one could also argue it's just a new ICE candidate type and extension.

So we're asking for MMUSIC to let SDP do it's job: advertise media-level capabilities and attributes.  

Maybe this would be easier to explain in an analogy.  Imagine if a very strict form of SRTP was required to be used by certain domains. (not too hard to imagine)  Would we (a) make all devices everywhere require support for that form of SRTP, or (b) make it a choice advertised in SDP?  

-hadriel

---

From: Emil Ivov <[email-masked]>
Date: Thu, 22 Apr 2010 19:55:36 +0200

На 22.04.10 19:09, Hadriel Kaplan написа:
> No, we are not "insisting to remove this feature" at all.  We are not
> asking to deprecate ICE, we are not suggesting endpoints should not
> implement ICE, and we are not suggesting they cannot use ICE.  Every
> proposal thus far has assumed that an endpoint which supports ICE
> would make an ICE offer.  It MAY also indicate additional
> capabilities in that offer (whatever those would be), but absolutely
> no one has suggested it would not also be able to use ICE if it ends
> up talking with another ICE-capable device.
> 
> All we're saying is that for a fairly common case in practice, ICE is
> not necessary and is cost-prohibitive and is thus not going to be
> implemented in some devices. 

The point is that devices that happen not to implement ICE are probably
not really meant to be deployed randomly over the Internet but rather
within specific environments. Once you start focusing on these
environments and stop considering the Internet then you'd probably be
better off using ANAT as others suggested, and stop worrying whether it
is obsoleted or not.

> Maybe this would be easier to explain in an analogy.  Imagine if a
> very strict form of SRTP was required to be used by certain domains.
> (not too hard to imagine)  Would we (a) make all devices everywhere
> require support for that form of SRTP, or (b) make it a choice
> advertised in SDP?

I guess the difference here is that use of ICE is not required by
certain domains. It's use is required by the diversity of the topologies
and use cases over the Internet.

Cheers,
Emil

---

From: <[email-masked]>
Date: Thu, 22 Apr 2010 20:07:02 +0200

Dear Dan, 
See inline.

Cheers
Med
________________________________________
De : [email-masked] [[email-masked]] de la part de Dan Wing [[email-masked]]
Date d'envoi : jeudi 22 avril 2010 18:41
À : 'Emil Ivov'
Cc : 'Marc Petit-Huguenin'; 'Gonzalo Camarillo'; [email-masked]
Objet : Re: [MMUSIC] IPv6 transition and ICE

A good question.

Med: ANAT can work if introduced in a new VoIP infrastructure but upgrading an already running VoIP Service platform to be IPv6-compliant and use IPv6 between two SBC/P-CSCF may lead to session failure to backward compatibility issues.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 Apr 2010 11:16:56 -0700

> Sent: Thursday, April 22, 2010 11:07 AM
> To: Dan Wing; 'Emil Ivov'
> Cc: 'Marc Petit-Huguenin'; 'Gonzalo Camarillo'; [email-masked]
> Subject: RE : [MMUSIC] IPv6 transition and ICE
> 
> 
> Dear Dan, 
> See inline.
> 
> Cheers
> Med
> Med: ANAT can work if introduced in a new VoIP infrastructure 
> but upgrading an already running VoIP Service platform to be 
> IPv6-compliant and use IPv6 between two SBC/P-CSCF may lead 
> to session failure to backward compatibility issues.

Ok.  Hence, the two proposals which are effectively doing
"ANAT using a=".

-d

---

From: <[email-masked]>
Date: Thu, 22 Apr 2010 20:21:21 +0200

Dear Marc,

Please see inline.

Cheers,
Med
________________________________________
De : [email-masked] [[email-masked]] de la part de Marc Petit-Huguenin [[email-masked]]
Date d'envoi : jeudi 22 avril 2010 18:21
À : Hadriel Kaplan
Cc : Gonzalo Camarillo; Dan Wing; [email-masked]
Objet : Re: [MMUSIC] IPv6 transition and ICE

Med: No. I think there is a misunderstanding here. What is asked by ALTC/ICE-microlite proposals is that when/where connectivity checks are not required, to be able to enclose two addresses of distinct AFs without supporting any STUN & cie  in order (hopefully) to use of IPv6 whenever possible between two service elements (SIP UA, SBC-BGF, etc). 

Med: I don't understand this notion of "decent citizen" here...Don't forget that ICE and all this NAT traversal has an extra cost which is due mainly to SIP design principles...In a controlled environments (e.g., use of private addresses with a dedicated conversational VC + embedding a SIP UA in the CPE), no NAT traversal issues are encountered...hence no need to support that extra cost.

---

From: <[email-masked]>
Date: Thu, 22 Apr 2010 20:21:44 +0200

Re-,

Inline.
________________________________________
De : Dan Wing [[email-masked]]
Date d'envoi : jeudi 22 avril 2010 20:16
À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Emil Ivov'
Cc : 'Marc Petit-Huguenin'; 'Gonzalo Camarillo'; [email-masked]
Objet : RE: [MMUSIC] IPv6 transition and ICE

Med: Yes.

-d

---

From: <[email-masked]>
Date: Thu, 22 Apr 2010 20:26:29 +0200

Dear Emil,

Please see inline.

Cheers,
Med
________________________________________
De : [email-masked] [[email-masked]] de la part de Emil Ivov [[email-masked]]
Date d'envoi : jeudi 22 avril 2010 19:55
À : Hadriel Kaplan
Cc : Marc Petit-Huguenin; Gonzalo Camarillo; Dan Wing; [email-masked]
Objet : Re: [MMUSIC] IPv6 transition and ICE

Med: ANAT suffers from a backward compatibility issue which is not the case of ALTC or ICE-microlite proposals. Upgrading an existing service platform and use ANAT to propose both IPv4 and IPv6 candidate addresses may lead to session failures..This is not desired. If we want to encourage smooth introduction of IPv6 in already running (controlled) VoIP service platforms, an alternative to ANAT should be defined.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 22 Apr 2010 11:44:42 -0700

On 04/22/2010 10:09 AM, Hadriel Kaplan wrote:
> 
> 
>> -----Original Message----- From: Marc Petit-Huguenin
>> [mailto:[email-masked]] Sent: Thursday, April 22, 2010 12:21 PM
>> 
>> 
>> The reason an endpoint that is connected on the Internet needs to 
>> implement ICE-lite is to help other endpoints that are deployed behind a
>> NAT.  By insisting to remove this feature, you are basically telling all
>> this endpoints that they cannot use ICE and that they need to find another
>> way to solve their problems when connecting to this endpoints (like more
>> SBCs?).
> 
> No, we are not "insisting to remove this feature" at all.  We are not asking
> to deprecate ICE, we are not suggesting endpoints should not implement ICE,
> and we are not suggesting they cannot use ICE.  Every proposal thus far has
> assumed that an endpoint which supports ICE would make an ICE offer.  It MAY
> also indicate additional capabilities in that offer (whatever those would
> be), but absolutely no one has suggested it would not also be able to use ICE
> if it ends up talking with another ICE-capable device.

The ICE endpoint still needs to do connectivity checks.  Why your endpoints,
because they do not need to do connectivity checks in direction of other
endpoints, would deny other endpoints the possibility to do connectivity checks
to them, and so forcing them to use a TURN server?

It's not about your endpoints.  It's about increasing the value of the *whole*
Internet by helping endpoints behind a NAT to have full connectivity.

> 
> All we're saying is that for a fairly common case in practice, ICE is not
> necessary and is cost-prohibitive and is thus not going to be implemented in
> some devices.  The problem we're trying to solve is the ability to offer both
> an IPv4 and IPv6 address, for these common cases.  Personally I think of this
> as completely orthogonal to ICE, but one could also argue it's just a new ICE
> candidate type and extension.
> 
> Maybe this would be easier to explain in an analogy.  Imagine if a very
> strict form of SRTP was required to be used by certain domains. (not too hard
> to imagine)  Would we (a) make all devices everywhere require support for
> that form of SRTP, or (b) make it a choice advertised in SDP?

---

From: Emil Ivov <[email-masked]>
Date: Thu, 22 Apr 2010 20:47:09 +0200

На 22.04.10 20:26, [email-masked] написа:
>> The point is that devices that happen not to implement ICE are
>> probably not really meant to be deployed randomly over the Internet
>> but rather within specific environments. Once you start focusing on
>> these environments and stop considering the Internet then you'd
>> probably be better off using ANAT as others suggested, and stop
>> worrying whether it is obsoleted or not.
> 
> Med: ANAT suffers from a backward compatibility issue which is not
> the case of ALTC or ICE-microlite proposals. Upgrading an existing
> service platform and use ANAT to propose both IPv4 and IPv6 candidate
> addresses may lead to session failures..This is not desired. If we
> want to encourage smooth introduction of IPv6 in already running
> (controlled) VoIP service platforms, an alternative to ANAT should be
> defined.

I understand this and my point was that if this alternative would only
work in some operators' environments then why worry whether or not it is
endorsed by the IETF. The people that would be building the
implementations would be building them exclusively for those operators
and not for deployment over the Internet.

Cheers,
Emil

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Apr 2010 14:48:39 -0400

> From: Emil Ivov [mailto:[email-masked]]
> Sent: Thursday, April 22, 2010 1:56 PM
> To: Hadriel Kaplan
> 

No one's worried about the deprecated status - it's that ANAT itself is useless to begin with.  It was useless before ICE, too.

Obviously we could just go define a new v4/v6 attribute for "closed networks" - we'd just go to 3GPP and define these SDP attributes there instead, since SDP attributes don't require an IETF RFC.

I don't know why the other authors want to do this in the IETF, but my reason for doing so is very simple: I want normal IETF-compliant SIP UA's to be able to understand the attribute in a received offer, and use it in their sent offer.  I want to be able to use it in a "closed network" AND over the public Internet.  I don't want to keep expanding separate SIP "worlds".

Otherwise what you're essentially telling me is that to be able to support IETF-compliant SIP UA's in a v4/v6 transition, current SIP providers need to spend more money than they would have to handle UA's which implemented 3GPP for a v4/v6 transition.  Being an active IETF member, I don't think that's a good position for the IETF to be in. 

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Apr 2010 14:50:46 -0400

> Of Dan Wing
> Sent: Thursday, April 22, 2010 2:17 PM
> 

Yup, pretty much.  Although the authors of ICE-microlite may argue otherwise.

I guess one could argue this is actually just a new ICE candidate-type for which no connectivity checks are needed/wanted.

-hadriel

---

From: <[email-masked]>
Date: Thu, 22 Apr 2010 20:56:39 +0200

Re-,

Please see inline.

Cheers,
Med
________________________________________
De : Emil Ivov [[email-masked]]
Date d'envoi : jeudi 22 avril 2010 20:47
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Hadriel Kaplan; Marc Petit-Huguenin; Gonzalo Camarillo; Dan Wing; [email-masked]
Objet : Re: RE : [MMUSIC] IPv6 transition and ICE

Med: I understand your point but we try to avoid proprietary solutions and rely on standardized tools.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Apr 2010 15:19:24 -0400

> Sent: Thursday, April 22, 2010 2:45 PM
> To: Hadriel Kaplan
> 

I think there's been a crossed wire somewhere.  We're not talking about "endpoints" not doing ICE.  We're talking about publicly accessible servers not doing ICE-Lite.

Let me try to paint a scenario we may all agree with.

Imagine a scenario like this:

   +-----+
   | ICE |
   | UA  | <----..__  ???
   +-----+          ``-..__        +-------+
      ^                    ``----> | PSTN  |
      | ICE         THE            |  GW   |
      |           INTERNET         +-------+
      v
   +-----+
   | ICE |
   | UA  |
   +-----+

Two endpoint UAs, possibly behind NATs.  
Their SIP provider "benevolent.ssp.com" offers a PSTN in/out calling service for these UAs.  They use a SIP PSTN-Gateway.  Today, their SIP PSTN-GW handles IPv4-based calls through latching, so there is no NAT issue.  They want the UA's to send media direct when possible, so they ask their customers to upgrade to ICE-capable UAs.  The UA's are just software running on PC's, so ICE is no big deal.  Cool, so now the UA-to-UA calls work without the help of the provider.

Now they want to also offer their PSTN in/out service over IPv6, because IANA told them the clock is ticking.  So they go to their PSTN-GW manufacturer and say "hey please do ICE-Lite so we can do IPv6 transition".  The PSTN-GW manufacturer says "No problem, but since this ICE stuff does Foo, it'll use up X more resources in our DSPs, so each PSTN-Gateway will only be able to handle Y calls."  The provider says "Crap! Did we need to do Foo before for IPv4?"  Vendor says "No, but the IETF has decided everyone must do Foo, for the good of the Internet".

Do you see a problem?

And this isn't a stretch - for the two "Internet"-based SIP providers we've mentioned on this list which use SIP+ICE on their UA's on the public Internet, neither of them use ICE for PSTN in/out calls to/from those UA's.  And it will cost them more to do so.  

-hadriel

---

From: Simon Perreault <[email-masked]>
Date: Thu, 22 Apr 2010 15:41:27 -0400

On 2010-04-22 15:19, Hadriel Kaplan wrote:
>     | UA  |<----..__  ???

Yes there is definitely a problem. The PSTN should do ICE-lite if it 
wants to help the ICE full UAs traverse the NATs they're behind. It 
doesn't matter if they're talking to each other or to the PSTN GW. When 
an ICE full UA wants to traverse a NAT, it needs its peer to be either 
ICE full or ICE-lite.

If you're on the Internet, you need to do ICE.

Otherwise, you may very well do whatever you want, thank you very much.

Simon

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 22 Apr 2010 12:51:55 -0700

> Imagine a scenario like this:

No, I do not.  Call it an Internet tax if you want. *I* do have to pay for
development and testing of ICE and pay for TURN servers bandwidth because of the
mess created by the NAT, I do not see why PSTN providers should be exempt of the
really minor increase in resource usage caused by ICE-lite.

---

From: Olivier Crête <[email-masked]>
Date: Thu, 22 Apr 2010 16:45:52 -0400

> Imagine a scenario like this:

No, they need ICE because there is no single IPv6 Internet. As Google
has told us, there are multiple islands of IPv6 on the Internet. So, if
you want to work reliably over the real public Internet, you need
connectivity checks, always.

Also, people seem to assume that current SIP PSTN gateways work. That's
a lie that only SIP people seem to believe in. I have accounts with a
couple of PSTN gatewats and more than half the time when I try to use
them from somewhere that is not home, they fail. But Skype always works.
Also, Google Talk almost always works. ICE really is required if you use
the real Internet, no way around it.

In summary, if you use the real Internet, please implement ICE (or
ICE-lite). If you are on a closed controlled network, you can do
whatever you want. But please, let's do all we can to discourage non-ICE
implementations or we will give the whole market over to Skype and open
standards will lose.

-- 
Olivier Crête
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Apr 2010 17:04:10 -0400

> Sent: Thursday, April 22, 2010 3:41 PM
> 

But it only needs that because an IETF RFC mandated it be done.  It doesn't need that to actually succeed in making or receiving a call to/from the PSTN.

> If you're on the Internet, you need to do ICE.

SIP calls are made every single day on the real, public Internet, without ICE.  So I'm not sure how this became a "need".  It's _sufficient_ to use ICE at all times, no doubt, but not _necessary_.

-hadriel

---

From: Jim Kleck <[email-masked]>
Date: Thu, 22 Apr 2010 14:53:14 -0700

inline...

Hadriel Kaplan wrote:

-----Original Message-----

And a good many of those SIP calls will go through a TURN server since
they dont use ICE to

find a better path. And the SIP service provider has to deploy and
maintain those TURN servers.

And the use of TURN servers increases to the load on the public
Internet. So there is an increased

cost for both the service provider and the public internet. Those costs
should also be considered.

Jim Kleck

-hadriel

---

From: Emil Ivov <[email-masked]>
Date: Thu, 22 Apr 2010 23:54:09 +0200

На 22.04.10 23:04, Hadriel Kaplan написа:
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Simon Perreault Sent:
>> Thursday, April 22, 2010 3:41 PM
>> 
>> Yes there is definitely a problem. The PSTN should do ICE-lite if
>> it wants to help the ICE full UAs traverse the NATs they're behind.
>> It doesn't matter if they're talking to each other or to the PSTN
>> GW. When an ICE full UA wants to traverse a NAT, it needs its peer
>> to be either ICE full or ICE-lite.
> 
> But it only needs that because an IETF RFC mandated it be done. 

Right. And the fact that nothing else worked had nothing to do with it.

> It
> doesn't need that to actually succeed in making or receiving a call
> to/from the PSTN.

Nope. And it doesn't need it to call a server and a client when both are
behind the same NAT. It doesn't need it when STUN works either. Should
we come up with IPv6 transition strategies for each of these cases too?

> SIP calls are made every single day on the real, public Internet,
> without ICE.  So I'm not sure how this became a "need".  It's
> _sufficient_ to use ICE at all times, no doubt, but not _necessary_.

Yes, and these SIP calls are almost always going through relays because
that's the only thing that always works. I don't think anyone would like
to continue down that same road.

Cheers,
Emil

---

From: Emil Ivov <[email-masked]>
Date: Fri, 23 Apr 2010 00:14:06 +0200

На 22.04.10 21:19, Hadriel Kaplan написа:
> Now they want to also offer their PSTN in/out service over IPv6,
> because IANA told them the clock is ticking.  So they go to their
> PSTN-GW manufacturer and say "hey please do ICE-Lite so we can do
> IPv6 transition".  The PSTN-GW manufacturer says "No problem, but
> since this ICE stuff does Foo, it'll use up X more resources in our
> DSPs, so each PSTN-Gateway will only be able to handle Y calls." 

Do you have any real world values for X and Y? I am having a hard time
imagining how ICE could ever make a difference on a PSTN gateway.

Off the top of my head, extra packets would probably represent less than
0.1% of total traffic (in a worst case scenario) and calculating
HMAC-SHA1s and CRCs for those packets could hardly be an issue for a
platform that already has to take care of all that transcoding.

> And this isn't a stretch - for the two "Internet"-based SIP providers
> we've mentioned on this list which use SIP+ICE on their UA's on the
> public Internet, neither of them use ICE for PSTN in/out calls
> to/from those UA's. 

And anyone else can do the same on a per session basis, without breaking
ICE support. (And then stop doing it when they realize that they do need
those ckecks after all).

---

From: Simon Perreault <[email-masked]>
Date: Thu, 22 Apr 2010 19:06:40 -0400

On 04/22/2010 05:04 PM, Hadriel Kaplan wrote:
> But it only needs that because an IETF RFC mandated it be done.  It

I don't understand why. What happens if the UA is behind a NAT? Or are
you assuming that latching is the way to go? Or are you still talking
about the ISP-controlled environment where the UA will never be a NAT,
in which case we shouldn't really be talking about "the Internet"?

Simon

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Apr 2010 19:16:06 -0400

> Sent: Thursday, April 22, 2010 6:14 PM
> 

Nope, I don't know what X really is for PSTN-GWs.  I don't build a PSTN-GW.  But the cost issue is what we've been told when we've asked them when they're going to do ICE-Lite.  One of the biggest PSTN-GW vendors don't even have traditional DSP's in their gateway usually, and their cost for having them doubles the system cost.  The PSTN-gateway market is very price sensitive. :(

Personally my use-case is different than the one I drew, and it's for when an SBC is the ICE-Lite side.  And the SBC would need to handle something on the order of 1,000-50,000 STUN packets per second.  For us we have optional hardware components to handle the SHA-1 overhead, but no one's going to pay for that hardware just to support ICE-Lite.  Without that hardware, we could still easily do connectivity check responses, but not with SHA-1. 

Maybe pure-Internet providers would pay the "tax" (maybe), but their market size is tiny compared to the "traditional" voip service provider market so you don't get the economies of scale.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 Apr 2010 16:38:53 -0700

> Sent: Thursday, April 22, 2010 12:19 PM
> To: Marc Petit-Huguenin
> > endpoints, would deny other endpoints the possibility to do 
> connectivity
> > checks
> > It's not about your endpoints.  It's about increasing the 
> value of the
> > *whole*
> I think there's been a crossed wire somewhere.  We're not 
> talking about "endpoints" not doing ICE.  We're talking about 
> publicly accessible servers not doing ICE-Lite.
> 
> Their SIP provider "benevolent.ssp.com" offers a PSTN in/out 
> calling service for these UAs.  They use a SIP PSTN-Gateway.  
> Today, their SIP PSTN-GW handles IPv4-based calls through 
> latching, so there is no NAT issue.  They want the UA's to 
> send media direct when possible, so they ask their customers 
> to upgrade to ICE-capable UAs.  The UA's are just software 
> running on PC's, so ICE is no big deal.  Cool, so now the 
> UA-to-UA calls work without the help of the provider.
> 
> Now they want to also offer their PSTN in/out service over 
> IPv6, because IANA told them the clock is ticking.  So they 
> go to their PSTN-GW manufacturer and say "hey please do 
> ICE-Lite so we can do IPv6 transition".  The PSTN-GW 
> manufacturer says "No problem, but since this ICE stuff does 
> Foo, it'll use up X more resources in our DSPs, so each 
> PSTN-Gateway will only be able to handle Y calls."  The 
> provider says "Crap! Did we need to do Foo before for IPv4?"  
> Vendor says "No, but the IETF has decided everyone must do 
> Foo, for the good of the Internet".
> 
> Do you see a problem?

Yes, I understand what you are describing.

However, I have a concern with removing connectivity checks
for this Internet-based service.

Background:

I assume IPv6 will be preferred over IPv4, as per RFC3484
rules.  Without connectivity checks, this means we are relying 
on IPv6 working at least as good as IPv4.  Experience to date
seems to indicate that IPv6 is worse (read: slower) in some
cases (e.g., 6to4 tunnels, Teredo tunnels), broken (IPv6
island, due to whatever reasons), or flaky (more loss due
to smaller and/or worse peering).  This has resulted in Google
and Yahoo (and others) wanting to whitelist certain ISPs
(a good reference is Jason Livingood's post at 
http://www.ietf.org/mail-archive/web/dnsop/current/msg08417.html
and Google's description of their whitelisting at
http://www.google.com/intl/en/ipv6/).

Concern:

How will we avoid this same problem?  Or do we, on the real
Internet, just do ICE (with connectivity checks) rather than 
the "ANAT using a=" proposal that is on the table.

> And this isn't a stretch - for the two "Internet"-based SIP 
> providers we've mentioned on this list which use SIP+ICE on 
> their UA's on the public Internet, neither of them use ICE 
> for PSTN in/out calls to/from those UA's.  And it will cost 
> them more to do so.  

To be clear, most of that cost is to do SHA1 for the 
connectivity checks?

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Apr 2010 19:56:55 -0400

> Sent: Thursday, April 22, 2010 7:39 PM
> 
> Concern:
> 

Yeah, it's a good point and Olivier and others have made it before about IPv6 being assumed to be reachable.  For the local access provider (what some are calling "closed networks", but to me are just "local networks") the v6-island problem is not an issue that seems to concern them.  But for the Internet from anywhere to anywhere it easily could be.

> To be clear, most of that cost is to do SHA1 for the

That's the only one I know of (and really care about), but that's just in the SBC space.  The PSTN-gateway issues constantly surprise me, due to so many different implementation designs.  For all I know some of them could have performance issues if for ICE-Lite they need extra signaling exchanges between their controller and media cards (e.g., in a MGCP/H.248 distributed PSTN-GW model).  But as far as I can tell for ICE-Lite that shouldn't be necessary.  Right?

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 Apr 2010 17:01:53 -0700

> Sent: Thursday, April 22, 2010 4:16 PM
> To: Emil Ivov
> Cc: Marc Petit-Huguenin; Gonzalo Camarillo; Dan Wing; [email-masked]
> Nope, I don't know what X really is for PSTN-GWs.  I don't 
> build a PSTN-GW.  But the cost issue is what we've been told 
> when we've asked them when they're going to do ICE-Lite.  One 
> of the biggest PSTN-GW vendors don't even have traditional 
> DSP's in their gateway usually, and their cost for having 
> them doubles the system cost.  The PSTN-gateway market is 
> very price sensitive. :(
> 
> Personally my use-case is different than the one I drew, and 
> it's for when an SBC is the ICE-Lite side.  And the SBC would 
> need to handle something on the order of 1,000-50,000 STUN 
> packets per second.  For us we have optional hardware 
> components to handle the SHA-1 overhead, but no one's going 
> to pay for that hardware just to support ICE-Lite.  Without 
> that hardware, we could still easily do connectivity check 
> responses, but not with SHA-1. 

Can we investigate how to do connectivity checks that don't use SHA1?

Two IDEAS FOR DISCUSSION, which retain connectivity checks and backwards
compatibility with ICE and ICE-Lite; if both peers support the idea, both
peers avoid HMAC-SHA1; if one peer agrees but the other doesn't, we don't save
anything:

Idea 1: a STUN username starting with "pacific" indicates a desire to do
HMAC-CRC32  and when validating if the HMAC-CRC32 fails try normal HMAC-SHA1.

Idea 2: a STUN username with "atlantic" indicates a desire to not do
MESSAGE-INTEGRITY at all.  

-d

> Maybe pure-Internet providers would pay the "tax" (maybe), 
> but their market size is tiny compared to the "traditional" 
> voip service provider market so you don't get the economies of scale.
> 
> -hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 22 Apr 2010 17:08:12 -0700

> Yeah, it's a good point and Olivier and others have made it 
> before about IPv6 being assumed to be reachable.  For the 
> local access provider (what some are calling "closed 
> networks", but to me are just "local networks") the v6-island 
> problem is not an issue that seems to concern them.  But for 
> the Internet from anywhere to anywhere it easily could be.
> 
> 
> That's the only one I know of (and really care about), but 
> that's just in the SBC space.  The PSTN-gateway issues 
> constantly surprise me, due to so many different 
> implementation designs.  For all I know some of them could 
> have performance issues if for ICE-Lite they need extra 
> signaling exchanges between their controller and media cards 
> (e.g., in a MGCP/H.248 distributed PSTN-GW model).  But as 
> far as I can tell for ICE-Lite that shouldn't be necessary.  Right?

Correct, with MGCP/H.248 the SDP is sent down to the PSTN 
gateway and -- assuming it understands ICE -- it will do the
ICE processing and connectivity checks.

To my knowledge, none of Cisco's PSTN gateways implement ICE.

However, as there isn't a call active on the DS0 when the 
connectivity checks occur, it seems reasonable to expect the
DSP has idle CPU to do the SHA1 calculation for the 
connectivity checks (rather than the host processor doing 
the SHA1 calculation).

-d

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Apr 2010 11:14:16 +0200

> Sent: 22 April 2010 19:51
> To: Dan Wing; [email-masked]; 'Emil Ivov'
[JRE] Even as an author of ice-microlite, I agree that it is basically a way of doing "ANAT using a=". Both proposals share that basic property, but differ in the details.

John

> 
> I guess one could argue this is actually just a new ICE 
> candidate-type for which no connectivity checks are needed/wanted.
> 
> -hadriel