Subject: Re: [MMUSIC] Comments on ICE-TCP specification RFC 6544

From: jakubadamek <[email-masked]>
Date: Tue, 25 Jun 2013 08:34:33 -0700 (PDT)

Hi Nigel,

could you please tell me roughly how much time it took to implement the RFC? 
And how well does it work for you?

Thx Jakub

--
View this message in context: http://ietf.10.n7.nabble.com/Comments-on-ICE-TCP-specification-RFC-6544-tp191890p373839.html
Sent from the IETF - mmusic mailing list archive at Nabble.com.

---

From: Nigel Pattinson <[email-masked]>
Date: Wed, 26 Jun 2013 20:41:02 -0700 (PDT)

jakubadamek wrote
> could you please tell me roughly how much time it took to implement the

That's difficult to say - we started from scratch, so had to implement STUN,
TURN (client and server), as well as Jingle. Probably the ICE portion was 2
- 3 man months.

jakubadamek wrote
> And how well does it work for you?

We haven't shipped yet, but it seems like it will work fine. However in
practice we suspect the outcome will be that host candidates will be used
within a LAN, and a relayed connection in almost all other cases. We have
all the usual ICE code for server and peer reflexive candidates, and for
simultaneous open TCP candidates, but we expect that the cases where they
can be successfully used to establish a connection will be rare.

Also as my previous post suggested, your TCP code may need to be more
different from UDP than the specification might lead you to believe.

In the end, if a relayed connection is an acceptable outcome and
peer-to-peer is a bonus, then ICE-TCP seems worth investigating. But if
peer-to-peer is the priority UDP might be the way to go.

Nigel

--
View this message in context: http://ietf.10.n7.nabble.com/Comments-on-ICE-TCP-specification-RFC-6544-tp191890p374094.html
Sent from the IETF - mmusic mailing list archive at Nabble.com.

---

From: Adam Roach <[email-masked]>
Date: Thu, 27 Jun 2013 00:15:02 -0500

On 6/26/13 22:41, Nigel Pattinson wrote:
> However in
> within a LAN, and a relayed connection in almost all other cases.

How many techniques from sections 5.3 and 5.4 did you implement? Did 
your implementation make use of the following advice?

    If the local network or host
    does not support IPv6 addressing,  clients SHOULD make use of
    other techniques, e.g., TURN-IPv6 [RFC6156], Teredo [RFC4380], or
    SOCKS IPv4-IPv6 gatewaying [RFC3089], for obtaining IPv6 candidates.

My experience is that Teredo-to-Teredo tunneling has success rates well 
above 50% (at least for RFC6081 implementations) -- although this is 
admittedly from my own personal use of Teredo, and is far from a 
scientific survey.

/a

---

From: Nigel Pattinson <[email-masked]>
Date: Sun, 30 Jun 2013 14:26:20 -0700 (PDT)

Adam Roach-3 wrote
> admittedly from my own personal use of Teredo, and is far from a 

To be clear my comments about success rates are largely speculation at the
moment. We do set up host candidates for Teredo where available. My
understanding of Teredo is limited, I was thinking that when a
Teredo-to-Teredo connection was established the traffic would still be
relayed, just via a Teredo relay rather than a TURN relay.

Nigel

--
View this message in context: http://ietf.10.n7.nabble.com/Comments-on-ICE-TCP-specification-RFC-6544-tp191890p374584.html
Sent from the IETF - mmusic mailing list archive at Nabble.com.

---

From: Adam Roach <[email-masked]>
Date: Sun, 30 Jun 2013 18:51:39 -0500

> relayed, just via a Teredo relay rather than a TURN relay.

I'm pretty sure that Teredo-to-Teredo traffic only has to go through a 
relay if both sides of the connection are behind symmetric NATs. It's 
been a while since I played around with it, though, so I might be 
misremembering.

/a