Subject: Re: [BEHAVE] Re: removing application milestone

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 17 Jul 2007 11:18:27 +0300

On Tuesday 17 July 2007 10:56:59 you wrote:
> Re: Battery life
> This isn't a concern to me, but I'd love to see the data on this.

http://www.niksula.hut.fi/~peronen/publications/haverinen_siren_eronen_vtc2007.pdf
And this is a very serious concern to *me*.

> Re: Server-poor
> I didn't follow the last bit -- I'm not sure what a "peer-to-peer
> server-poor environment" is.  This is designed for and proven in the real
> world internet at a very large scale around the globe.  Are you suggesting
> that somehow ICE is better adapted for reality than this system, or that
> this system is somehow better suited for some other environment than the
> one it's currently being used in?

If you have lots of servers with enough bandwidth that you do not try to 
minimize the volume of signaling, then using multiple and dymanically 
generated candidates (as ICE calls them) is bound to yield better results 
than a single candidate that would be computed at application startup.

How much better "better" is, possibly not so significant.

-- 
Rémi Denis-Courmont

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "David Barrett" <[email-masked]>
Date: Tue, 17 Jul 2007 01:25:19 -0700

> -----Original Message-----
> From: Rémi Denis-Courmont [mailto:[email-masked]]
> 

Cool, thanks!

> How much better "better" is, possibly not so significant.

I'm still not sure I see how this is the case.  Can you give me a very
precise example of how ICE (in theory) does better?

Whether you do your STUN operation immediately before the connection or you
keep doing it continuously (as per the design I'm using), it comes up with
the same results.  Except my results are readily available, and thus the
connection establishes quicker.

If this isn't the case, can you please give a very clear example of why it's
better to do it right before connection establishment instead of on startup
and continuously thereafter?

-david