RE: BoF request: STUN Control Usage

> > -----Original Message-----
> > From: Dan Wing [mailto:dwingcisco.com]
> > Subject: [BEHAVE] BoF request: STUN Control Usage
> > 
> >  1. ICE works.  This has been well demonstrated by
its successful
> >     deployment on the Internet by millions of
endpoints.  It works
> >     without explicit support by subscriber's NATs
or ISP's NATs.
> 
> Just curious, what statistics are available on ICE's 
> real-world usage and NAT-penetration success rates? 
Specifically:
> 
> - How did you come up with the "millions of
endpoints" number?

GoogleTalk's API, Google Talk itself, Microsoft's Windows
Live
Messenger (formerly called MSN), and Yahoo Messenger all use

ICE.

> - What does "works" mean?  (I'd suggest this
be measured in 
> "direct peer connectivity ratio" and
"connection setup time", 
> but any measure will do.)

I found this, "Improving ICE Service Selection in a P2P
System 
using the Gradient Topology", 
http://www.jimdowling.info/pubs/dowling-j_icep2p_saso
07.pdf
which includes the following quote:

  [...] Google's estimate that 8% of the GoogleTalk traffic

  is routed using relay nodes.

which cites
  Google. Google talk, Accessed, Feb 22, 2007.
  http://cod
e.google.com/apis/talk/libjingle

which leads one to:
  http://code.google.com/apis/talk/libjingle/imp
ortant_concepts.html

> Granted, it might be a bit OT given that you're really
trying 
> to talk about STUN, but I'm always interested in new
real-world 
> statistics.

It's a worthwhile discussion, even if a bit off topic.


If STUN/ICE were more, or less, common on the Internet would
you
find a BoF on optimizing STUN more, or less, important?

-d


_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave

> -----Original Message-----
> From: Dan Wing [mailto:dwingcisco.com]
> 
> > > -----Original Message-----
> > > From: Dan Wing [mailto:dwingcisco.com]
> > > Subject: [BEHAVE] BoF request: STUN Control
Usage
> > >
> > >  1. ICE works.  This has been well
demonstrated by its successful
> > >     deployment on the Internet by millions of
endpoints.  It works
> > >     without explicit support by subscriber's
NATs or ISP's NATs.
> >
> > Just curious, what statistics are available on
ICE's
> > real-world usage and NAT-penetration success
rates?  Specifically:
> >
> > - How did you come up with the "millions of
endpoints" number?
> 
> GoogleTalk's API, Google Talk itself, Microsoft's
Windows Live
> Messenger (formerly called MSN), and Yahoo Messenger
all use
> ICE.

Ok, that's true, ICE code exists on millions of computers. 
I wonder what
fraction of those clients actually use the VoIP features,
however.  It'd be
neat to know how (or estimate) many ICE sessions are
established daily,
especially as a fraction of total P2P VoIP connections.

Incidentally, do you know if it's possible to establish VoIP
communications
between these networks?  Has it been demonstrated that these
different ICE
implementations are in fact compatible, or are they more
"ICE-influenced"?


> > - What does "works" mean?  (I'd suggest
this be measured in
> > "direct peer connectivity ratio" and
"connection setup time",
> > but any measure will do.)
> 
> I found this, "Improving ICE Service Selection in
a P2P System
> using the Gradient Topology",
> http://www.jimdowling.info/pubs/dowling-j_icep2p_saso
07.pdf
> which includes the following quote:
> 
>   [...] Google's estimate that 8% of the GoogleTalk
traffic
>   is routed using relay nodes.

Very cool, thanks!


> > Granted, it might be a bit OT given that you're
really trying
> > to talk about STUN, but I'm always interested in
new real-world
> > statistics.
> 
> It's a worthwhile discussion, even if a bit off topic.
> 
> If STUN/ICE were more, or less, common on the Internet
would you
> find a BoF on optimizing STUN more, or less,
important?

Well, I don't know the answers to the above questions I
pose, but I'd wager
that the actual utility of ICE in the real world today is
less dramatic than
"millions of endpoints" would suggest.  If that's
true (and I have no data
to suggest it is or isn't), I'd suggest that perhaps we
should work on
determining why ICE isn't more widely used and focus on
that.  

For example, has it been proven that different ICE
implementations
interoperate as smoothly in practice as they should in
theory?  If not, what
real-world lessons can be drawn and applied to perhaps
improve practical
interoperability going forward?  92% peer connectivity is
pretty good --
perhaps there are bigger fish to fry than getting to 95% or
99%?

And while I realize this is all about ICE, I think this
might be relevant to
STUN because there are a finite number of people in the IETF
working on P2P,
and their time is a scarce commodity.  Given that ICE is
STUN's primary
customer, STUN's fortunes sink or swim with ICE's (just as
ICE's fortunes
sink or swim on SIP's).  

As such, until it's been demonstrated that ICE and SIP are
already swimming
(which they might be), I'd be hesitant to spend much energy
on expanding
STUN beyond the strict functionality required by ICE and
would instead
refocus that effort on making ICE and SIP more relevant in
the real world.

Said another way, until some measurable, significant
fraction (25%?) of the
world's P2P VoIP calls use a SIP/ICE/STUN stack, I think the
focus should be
on smoothing out the practical wrinkles that prevent greater
adoption over
improving the theoretical capabilities of an underutilized
protocol.

Reducing chattiness of STUN sounds great, but the amount of
energy it'll
take to not only standardize the protocol but push standard
implementation
into a significant portion of the world's NATs seems high. 
If we could
measure all that energy into manhours, I wonder what better
way those hours
might be spent?

-david



_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave

Hi, 

>Given that ICE is STUN's primary customer, STUN's
fortunes 
>sink or swim with ICE's (just as ICE's fortunes
>sink or swim on SIP's).  

I think this statement is a bit exaggerated. There
are already SIP VoIP UA implementations with RFC
3489 version of STUN but without ICE. They are
succesfully deployed with environments where the
NATs implement Endpoint-Independent Mapping behaviour.

Thus fates of STUN and ICE are not as tightly connected
to each other as you suggest. ICE provides added value
for complex environments, but there are significant
deployments which already work pretty well just with
SIP combined with STUN.

>As such, until it's been demonstrated that ICE and SIP
are 
>already swimming (which they might be), I'd be hesitant
to 
>spend much energy on expanding STUN beyond the strict 
>functionality required by ICE and would instead refocus

>that effort on making ICE and SIP more relevant in the 
>real world.

For the deployments I am referring to, it would be useful
to have STUN extended with a mechanism to control the
required keepalive interval for NAT binding:

- Extensions needed for the already deployed set of 
  protocols would be minimal.

- There would be significant benefits both to the
  traffic in the network and the battery consumption
  of mobile VoIP devices.

So I think this effort is valuable regardless on what
happens to ICE.

Regards,

Erkki


_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave

Hi,

I think that SIP outbound is as "primary" customer
of STUN as ICE is.

Regards,

Christer

> -----Original Message-----
> From: Erkki.Koivusalonokia.com
[mailto:Erkki.Koivusalonokia.com] 
> Sent: 8. kesäkuuta 2007 9:44
> To: dbarrettquinthar.com
> Cc: behaveietf.org
> Subject: RE: [BEHAVE] BoF request: STUN Control Usage
> 
> Hi, 
> 
> >Given that ICE is STUN's primary customer, STUN's
fortunes 
> sink or swim 
> >with ICE's (just as ICE's fortunes sink or swim on
SIP's).
> 
> I think this statement is a bit exaggerated. There are

> already SIP VoIP UA implementations with RFC
> 3489 version of STUN but without ICE. They are
succesfully 
> deployed with environments where the NATs implement 
> Endpoint-Independent Mapping behaviour.
> 
> Thus fates of STUN and ICE are not as tightly connected
to 
> each other as you suggest. ICE provides added value for

> complex environments, but there are significant
deployments 
> which already work pretty well just with SIP combined
with STUN.
> 
> >As such, until it's been demonstrated that ICE and
SIP are already 
> >swimming (which they might be), I'd be hesitant to
spend 
> much energy on 
> >expanding STUN beyond the strict functionality
required by ICE and 
> >would instead refocus that effort on making ICE and
SIP more 
> relevant 
> >in the real world.
> 
> For the deployments I am referring to, it would be
useful to 
> have STUN extended with a mechanism to control the
required 
> keepalive interval for NAT binding:
> 
> - Extensions needed for the already deployed set of
>   protocols would be minimal.
> 
> - There would be significant benefits both to the
>   traffic in the network and the battery consumption
>   of mobile VoIP devices.
> 
> So I think this effort is valuable regardless on what
happens to ICE.
> 
> Regards,
> 
> Erkki
> 
> 
> _______________________________________________
> Behave mailing list
> Behaveietf.org
> https:/
/www1.ietf.org/mailman/listinfo/behave
> 


_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave

To take this a step further, I think sip-outbound is the
primary 
benefactor of stun-control, not ICE.

The big pain point today are these awful keepalives we need
to 
constantly be sending for sip-outbound. WHen UDP is used,
its every 20 
or 30 seconds. That represents a huge load on the servers
even when its 
STUN (though much better than REGISTER like what SBCs use
today). With 
stun control, we could control this so that SIP servers
would see 
reduction in stun volume by one or even two orders of
magnitude. That is 
a real big bang for the buck. Also benefits wireless
applications.

-Jonathan R.

Christer Holmberg (JO/LMF) wrote:

> Hi,
> 
> I think that SIP outbound is as "primary"
customer of STUN as ICE is.
> 
> Regards,
> 
> Christer
> 
> 
>>-----Original Message-----
>>From: Erkki.Koivusalonokia.com
[mailto:Erkki.Koivusalonokia.com] 
>>Sent: 8. kesäkuuta 2007 9:44
>>To: dbarrettquinthar.com
>>Cc: behaveietf.org
>>Subject: RE: [BEHAVE] BoF request: STUN Control
Usage
>>
>>Hi, 
>>
>>
>>>Given that ICE is STUN's primary customer,
STUN's fortunes 
>>
>>sink or swim 
>>
>>>with ICE's (just as ICE's fortunes sink or swim
on SIP's).
>>
>>I think this statement is a bit exaggerated. There
are 
>>already SIP VoIP UA implementations with RFC
>>3489 version of STUN but without ICE. They are
succesfully 
>>deployed with environments where the NATs implement

>>Endpoint-Independent Mapping behaviour.
>>
>>Thus fates of STUN and ICE are not as tightly
connected to 
>>each other as you suggest. ICE provides added value
for 
>>complex environments, but there are significant
deployments 
>>which already work pretty well just with SIP
combined with STUN.
>>
>>
>>>As such, until it's been demonstrated that ICE
and SIP are already 
>>>swimming (which they might be), I'd be hesitant
to spend 
>>
>>much energy on 
>>
>>>expanding STUN beyond the strict functionality
required by ICE and 
>>>would instead refocus that effort on making ICE
and SIP more 
>>
>>relevant 
>>
>>>in the real world.
>>
>>For the deployments I am referring to, it would be
useful to 
>>have STUN extended with a mechanism to control the
required 
>>keepalive interval for NAT binding:
>>
>>- Extensions needed for the already deployed set of
>>  protocols would be minimal.
>>
>>- There would be significant benefits both to the
>>  traffic in the network and the battery
consumption
>>  of mobile VoIP devices.
>>
>>So I think this effort is valuable regardless on
what happens to ICE.
>>
>>Regards,
>>
>>Erkki
>>
>>
>>_______________________________________________
>>Behave mailing list
>>Behaveietf.org
>>https:/
/www1.ietf.org/mailman/listinfo/behave
>>
> 
> 
> 
> _______________________________________________
> Behave mailing list
> Behaveietf.org
> https:/
/www1.ietf.org/mailman/listinfo/behave
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex
Plaza
Cisco Fellow                                   Parsippany,
NJ 07054-2711
Cisco Systems
jdrosencisco.com                              FAX:   (973)
952-5050
http://www.jdrosen.net 
                       PHONE: (973) 952-5000
http://www.cisco.com


_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave