Subject: Re: [MMUSIC] draft-lowekamp-mmusic-ice-tcp-framework-00 draft submitted

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Nov 2008 11:46:55 -0500

Bruce and Adam,

Thanks for putting this together. I think this is a fine idea and 
totally consistent with ICE. Indeed, folks may recall that earlier 
versions of the core ICE spec were also written to allow a wide variety 
of UDP based mechanisms, including some of the ones listed in this 
document. We pulled it out in the big ice-9 rewrite because it was just 
too hard to understand and complicated things.

The main questions that I have, however, are these:

* if a client did everything listed in the document, what would be the 
success rate for direct host to host tcp connections? Is there a 
particular technique which gives the biggest bang for the buck?

* related to the previous point, which of these various things would we 
actually mandate? I'm worried that, if we leave it as just this open 
framework, it doesn't really help an implementor figure out what they 
need to actually DO to make it work

On the terminology, I'm not convinced we need anything new beyond host, 
server-reflexive, relayed. Those are not tied to a specific protocol. 
UPnP and NAT-PMP for example would be examples of server reflexive. I 
also don't see why those would be prioritized over the stun-dervied 
server reflexive ones.

The draft gives details for SIMCO, MIDCOM, RSIP - lets be practical here 
and only include details for stuff thats in real usage. We can always 
add specs later for additional protocols.

The UDP tunneled stuff and TCP relayed stuff is more complicated because 
we really HAVE to pick a mandatory mechanism. Otherwise, a service 
provider that wants to support an ICE-enabled app, will not know what 
kind of servers it needs to deploy. Teredo? TURN-TCP? SSH server?

I'd also like to see more details on the Teredo solution.

Thanks,
Jonathan R.

Bruce Lowekamp wrote:
> Adam Roach and I have just submitted a draft proposing a way to move
> ICE-TCP forward by expanding the techniques it uses to gather
> candidates.  This draft came out of some ideas discussed on the list
> prior to Dublin and a conversation with Jonathan in Dublin.
> 
> Please read and comment.  It's rough, but we hope progress can be made
> improving ICE-TCP's success rate with direct connections.
> 
> Bruce
> 
> ------------
> 
> http://www.ietf.org/internet-drafts/draft-lowekamp-mmusic-ice-tcp-framework-00.txt
> 
> Title:    A Proposal to Define Interactive Connectivity Establishment
> for the Transport Control Protocol (ICE-TCP) as an Extensible
> Framework
> 
> Abstract:
> The ICE-TCP mechanism is currently regarded as of limited usefulness
> due to the low success rate of TCP simultaneous open for NAT
> traversal.  This document presents a vision of the ICE-TCP document
> as an extensible framework for negotiating a variety of approaches
> for establishing a TCP connection between NATed hosts.  This document
> further proposes significantly extending the current set of
> collection mechanisms to encompass a wide variety of technologies
> that are currently available, including UPnP, SOCKS, and Teredo.
> Because several of these technologies are already widely deployed,
> the direct connection rate should be significantly higher than using
> straight TCP alone.  We envision that as future TCP connection
> establishment techniques are developed, they too will specify an ICE
> encoding that will allow their negotiation.
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Adam Roach <[email-masked]>
Date: Fri, 14 Nov 2008 12:03:54 -0600

> particular technique which gives the biggest bang for the buck?

The chance of a client having access to *none* of these techniques is, 
in my opinion, vanishingly small.

Unfortunately, it's a bit hard to get solid numbers on the penetration 
of each technique, so we'll have to make some guesses.

Of the techniques we list, the biggest bang for the buck right now is 
probably Teredo. There are a fair number of free Teredo servers 
available on the network (the load on a Teredo server for any given 
client is very, very low). I really encourage you to play around with 
the Teredo support in Windows and/or download the Miredo client for the 
operating system of your choice. It's amazing how well it works, and how 
it "just works" without any fidgeting.

Behind that is probably UPnP IGD -- my experience is that most 
residential NATs implement it (although many, if not most, ship with it 
turned off by default). I'd love to have hard numbers here -- maybe 
Cullen can survey his pile of consumer NATs?

The UPnP story will be well boosted by the NAT-PMP penetration. Here, we 
*can* get hard numbers -- 10.6% [1] of the wifi access points (which 
currently represents the vast majority of residential NATs) support NAT-PMP.

TCP over UDP, depending on how it is fashioned, should have a success 
rate similar to Teredo; the downside is that it requires additional 
standardization (both the transport itself and SDP syntax) and 
significant implementation.

After that, my gut feel is that success is to be found primarily in 
relayed technologies -- in order of probable availability (IMHO): SOCKS, 
SSH Tunnels, and TURN TCP.

>
> * related to the previous point, which of these various things would 
> we actually mandate? I'm worried that, if we leave it as just this 
> open framework, it doesn't really help an implementor figure out what 
> they need to actually DO to make it work

That's kind of the point -- I don't think we mandate any specific 
technique -- I think we mandate interfaces made available to the other 
end with certain properties. At least one IPv6; at least one IPv4. At 
least one non-relayed.

>
> On the terminology, I'm not convinced we need anything new beyond 
> host, server-reflexive, relayed. Those are not tied to a specific 
> protocol. UPnP and NAT-PMP for example would be examples of server 
> reflexive. I also don't see why those would be prioritized over the 
> stun-dervied server reflexive ones.

We want to try them sooner, because they have a higher chance of 
working. We also have better visibility, from the client, into what 
happened if they stop working, and perhaps a chance to fix them without 
entering an ICE renegotiation.

> The draft gives details for SIMCO, MIDCOM, RSIP - lets be practical 
> here and only include details for stuff thats in real usage. We can 
> always add specs later for additional protocols.

I'm okay moving those out, or simply mentioning them as potential future 
candidates if they see wide deployment.

> The UDP tunneled stuff and TCP relayed stuff is more complicated 
> because we really HAVE to pick a mandatory mechanism. Otherwise, a 
> service provider that wants to support an ICE-enabled app, will not 
> know what kind of servers it needs to deploy. Teredo? TURN-TCP? SSH 
> server?

I understand your point, but am having a hard time reconciling it with 
what Bruce and I were trying to achieve with this document. Our approach 
is a client-centric one, in which we assume that the technologies that 
will be available at any given time are a grab bag. I may be able to use 
some techniques at home, different ones at work, others when I'm sitting 
in a cafe using WiFi, and yet again others when I'm at a hotel. The idea 
is that I should have a single client capable of operating in radically 
different network environments, many of which won't care about the 
ability to set up SIP sessions.

Your point is coming more from the perspective of a carefully-controlled 
deployment, where service providers have fairly rigid control of the 
network, from the infrastructure all the way down to the clients. Under 
these circumstances, the "mandatory" protocol is whatever the carrier 
puts in their RFP, regardless of what the IETF decides is appropriate.

> I'd also like to see more details on the Teredo solution.

I plan to add them -- time did not allow a full explanation of each 
protocol this time.

/a

[1] 
http://www.appleinsider.com/articles/08/05/22/apples_airport_grabs_10_6_share_of_802_11n_wifi_market.html
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Sat, 15 Nov 2008 18:02:18 -0500

On Fri, Nov 14, 2008 at 1:03 PM, Adam Roach <[email-masked]> wrote:
>> framework, it doesn't really help an implementor figure out what they need
>> to actually DO to make it work
>
> That's kind of the point -- I don't think we mandate any specific technique
> -- I think we mandate interfaces made available to the other end with
> certain properties. At least one IPv6; at least one IPv4. At least one
> non-relayed.
>
>>
>> server-reflexive, relayed. Those are not tied to a specific protocol. UPnP
>> and NAT-PMP for example would be examples of server reflexive. I also don't
>> see why those would be prioritized over the stun-dervied server reflexive
>> ones.
>
> We want to try them sooner, because they have a higher chance of working. We
> also have better visibility, from the client, into what happened if they
> stop working, and perhaps a chance to fix them without entering an ICE
> renegotiation.

One of the nice things about most of these protocols is that the
client itself knows whether it has them or not.  The other nice thing
is that many are one-sided; they appear (and work) entirely as a
regular transport address to the remote side.   This means mandating
what specifically needs to be supported is not necessary (it's not a
compatibility issue where both sides need to agree).  Actually, I'm
not even sure that the UPnP IGD/NAT-PMP need to be normative
references.  The lesson is, if you can allocate a NAT-Assisted
transport address, you should, and then advertise it essentially as a
regular candidate.  The list of current protocols for doing that, and
the procedure for doing it, is mostly an informational snapshot of
current technology.

Regarding terminology, if we start looking at more exotic tunneling
protocols (those that don't present as a standard address like Teredo
does) such as using ssh tunnels, we'll need to have a different way of
encoding them.  I don't know if anything needs to be said about that
in the ice-tcp draft, but it's important that implementers know that
there may be candidate line they don't support.

Choosing between a STUN server-reflexive and a UPnP/NAT-PMP is a
little more complicated.  In a world with only one layer of NATs, you
would always prefer the UPnP/NAT-PMP candidate.  The only scenario I'm
aware of where the server-reflexive is more likely to work is
double-NAT where the remote peer is outside the second NAT layer.

>> and only include details for stuff thats in real usage. We can always add
>> specs later for additional protocols.
>

Part of our goal with this draft was to list a full spectrum of
possibilities, mostly to illustrate that there are so many ways of
doing this.  There's a smaller subset that work now, have a viable
spec, and could be written up in a draft that could be moved forward
very quickly (either the base ice-tcp draft or as a standalone draft).
 I agree it makes sense to separate these out for the sake of making
progress.

Bruce