Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-ice-tcp-10.txt

From: Tom Kristensen <[email-masked]>
Date: Tue, 9 Nov 2010 09:26:22 +0100

When this draft was revived for IETF-78, Maastricht, one of the things
that happened was that a new appendix aimed at documenting the
limitiations of ICE-TCP.
Cf.: http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-10#appendix-A

The second paragraph here was also present elsewhere in the previous
version(s), and references a SIGCOMM paper from 2005. Here the
simultaneous-open technique was found to work in something like 45% of
the cases. This is not too promising when considering the need for
infrastructure support needed, i.e. upgrading existing equipment or
deploying new boxes to handle TCP traffic.

I I remember correctly, on of the issues to be handled in upcoming
versions of this draft was to explore the field of today - hoping that
new versions of NATs and operating systems would lead to a better
success rate when it comes to number of direct connections. Any work
done or started in this area?

-- Tom

On 26 October 2010 15:33, Ari Keranen <[email-masked]> wrote:
> Hi all,
>
> This update contains mostly editorial fixes. The only technical change was
> the added instructions on how to encode the UDP-tunneled candidates in the
> SDP offer/answer. The draft now says:
>
>   UDP-tunneled candidates can be encoded in the ICE offer and answer
>   either as relayed or server reflexive candidates, depending on
>   whether the tunneling protocol utilizes a relay between the hosts.
>
> The other option would have been to add a new candidate-type to the SDP
> encoding of the ICE candidates but this is a simpler option and at least so
> far no one has mentioned that they'd prefer the other option.
>
>
> Cheers,
> Ari
>
> On 10/25/2010 06:15 PM, [email-masked] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Multiparty Multimedia Session Control
>> Working Group of the IETF.
>>
>>
>>        Title           : TCP Candidates with Interactive Connectivity
>> Establishment (ICE)
>>        Author(s)       : J. Rosenberg, et al.
>>        Filename        : draft-ietf-mmusic-ice-tcp-10.txt
>>        Pages           : 25
>>        Date            : 2010-10-25
>>
>> Interactive Connectivity Establishment (ICE) defines a mechanism for
>> NAT traversal for multimedia communication protocols based on the
>> offer/answer model of session negotiation.  ICE works by providing a
>> set of candidate transport addresses for each media stream, which are
>> then validated with peer-to-peer connectivity checks based on Session
>> Traversal Utilities for NAT (STUN).  ICE provides a general framework
>> for describing candidates, but only defines UDP-based transport
>> protocols.  This specification extends ICE to TCP-based media,
>> including the ability to offer a mix of TCP and UDP-based candidates
>> for a single stream.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-tcp-10.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [email-masked]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/

---

From: Ari Keranen <[email-masked]>
Date: Tue, 09 Nov 2010 17:47:43 +0800

Hi Tom,

> deploying new boxes to handle TCP traffic.

True, and that was the main reason for adding the new mechanisms 
(NAT-assisted, UDP-tunneled, etc.) to the draft. These mechanisms (e.g., 
Teredo and UPnP) should increase the success probability quite a bit, 
but without knowing how well they are supported, giving any exact 
numbers is really hard; about which there will a new paragraph in the 
next revision of the draft in the limitations section.

> done or started in this area?

I asked some people who had previously done research on this, but they 
had no more recent results. I'm still planning to ask from some folks at 
the meeting, but there's a good chance that this will remain as a "know 
limitation".

Cheers,
Ari

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 10 Nov 2010 04:16:41 +0100

> next revision of the draft in the limitations section.

OK and thanks! Of course, as time goes by people will eventually 
prototype/implement ICE-TCP and possibly (some of) these proposed 
extensions. Then it's possible to do some exploration and testing of the 
success rate of direct connections.

A possibly naive question regarding for instance UDP-tunnelling: Will 
the ICE-TCP draft specify in some detail how to signal and apply 
specific tunnelling approaches? Any normative or recommended schemes 
needed if that's the case?

> the meeting, but there's a good chance that this will remain as a "know

Yes, I think it will indeed remain a known limitation. Let's hope this 
known limitation is documented to some sense - based on implementer's 
experience, networks and operating systems.

-- Tom

---

From: Ari Keranen <[email-masked]>
Date: Wed, 10 Nov 2010 16:11:55 +0800

> needed if that's the case?

No, that would be out of scope for this draft. Overall the idea was to 
not have anything normative on any of the specific NAT assisted and UDP 
tunneled methods.

> experience, networks and operating systems.

Actually, there are ongoing efforts to measure behavior of different 
middleboxes (last BEHAVE meeting had a presentation of that) that could 
eventually give some more up-to-date information on this.

Cheers,
Ari