Subject: [p2p-sip] SIP, ICE, and an Overlay Network

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 17 Mar 2006 12:25:53 -0800

Maybe my limited knowledge of nat penetration leaves us on different pages.

Just few questions:

1. If peers behind all types of nats can establish direct connection between
each other *easily or anyway", why TURN comes up? (even Skype seems using
some kind of TURN relay)

2. If using two internal ports doubles risk of failure of connection
establishment, does it mean that, for two hosts behind a nat, after one host
gets connected (inward or outward), another will be double harder to get
connected??

3. If the overhead to open a udp socket can be ignored (it can be usually),
does it need double cpu/bandwidth to use the udp socket to communicate with
two peers?

4. From the sentence, "I *love* the idea of standardizing this behavior.  It
works great for me and my users", I thought one-port approach will loved to
be standardized. Sorry, I misunderstood your *love* :-)

I do (+ did) *love* the idea of port convergence, though. Actually when a
secure transport layer is necessarily beneath all packet streams for p2p
security, one-port approach is indeed as sweet as you love to suggest.

peter
----- Original Message -----
From: "David Barrett" <dbarrett at quinthar.com>
To: "'Peter Pan'" <huang-ming.pan at comcast.net>; "'Roy, Radhika R.'"
<RADHIKA.R.ROY at saic.com>; "'Michael Slavitch'" <slavitch at objectworld.com>;
"'Greg Daley'" <gregd at research.panasonic.com>; "'Michael Slavitch'"
<slavitch at gmail.com>
Cc: "'P2P-SIP'" <p2p-sip at cs.columbia.edu>
Sent: Friday, March 17, 2006 11:32 AM
Subject: RE: [p2p-sip] SIP, ICE, and an Overlay Network

> > -----Original Message-----
> > From: Peter Pan [mailto:huang-ming.pan at comcast.net]
> > Subject: Re: [p2p-sip] SIP, ICE, and an Overlay Network
> >
> > Multiplexing packet streams of different types on one UDP port seems no
> > different from (and no more helpful than) on separate udp ports when a
UA
> > is
> > behind symmetric nat, regarding nat penetration.
>
> Hm, I'm not sure I follow you:
>
> - Assuming it costs X (time, CPU, bandwidth, risk of failure) to establish
a
> connection between two peers, and
>
> - Assuming I need to establish 5 different connections between each pair
of
> peers (SIP, RTP-audio, RTP-video, RTP-filetransfer, RTP-screenshare), then
>
> - It's 5X (longer, more expensive, more bandwidth-intensive, greater risk
of
> partial failure) to use separate UDP ports than to re-use the same port.
>
> And this is true regardless of what kind of NAT or firewall you're behind
> (obviously, the more complex the environment, the more advantageous
> multiplexing becomes).
>
> Am I misunderstanding what you were saying?  I'm saying it's better to do
a
> risky and expensive operation once, rather than five times.
>
>
> > When a node is behind symmetric nat, if its signaling msg can be
forwarded
> > via one supernode while its media msg can be via another, the two msg
> > streams actually create two external port mappings.
>
> Perhaps this is the hangup: I'm suggesting that once the *direct*
connection
> is established between peers, *no* supernode does forwarding.
>
> Again, relay is *not* the same as NAT penetration.  NAT penetration is the
> art of establishing a direct P2P connection between *two* peers, without
> relying upon a third middleman (except for the connection establishment,
but
> then he gets out of the picture).
>
>
> > Especially for p2p-sip nodes to be backward compatible with
client/server
> > sip world, where proxy/ua/getway are normally separately located and
> > anyway
> > there are different external port mappings for all types of packet
> > streams,
> > standardizing one single port for all msg streams may hinder modular
> > design
> > of p2p-sip applications.
>
> I'm not sure we're talking about the same thing, but I'm suggesting that
> each UA be able to specify an arbitrary set of (ip:port) for its services.
> A UA can optionally use different ports for all services like today, or it
> can optionally use the same (ip:port) for all services.
>
> Anyway, I'm just following Roy's suggestion that in a P2P environment when
> the connection setup cost is so high, it's useful to reuse a single
> (ip:port) for everything.  But I'm certainly not proposing that we mandate
a
> single (ip:port) for everyone.  I'm merely suggesting we might standardize
> 'best practices' along these lines to simplify and regularize SIP in a P2P
> environment.
>
> -david
>
>
>

---

From: dbarrett at quinthar.com (David Barrett)
Date: Fri, 17 Mar 2006 13:03:53 -0800

> each other *easily or anyway", why TURN comes up? (even Skype seems using

Even the best NAT penetration isn't 100% reliable, so the TURN service is
the fall back plan.  But NAT penetration over 75% is straightforward, and
high 90% is possible -- even >99% has been claimed.

> gets connected (inward or outward), another will be double harder to get

Ah, no I'm referring to the prospect of partial failure.  For example, in
iGlance you can text-chat, voice-chat, videoconference, screen share, and
send files.  Were each of these using a different connection, the risk that
at least one of these channels fails to penetrate the NAT goes up.  And then
you're faced with the problem where your video channel is direct P2P, while
your audio channel is relayed through a TURN server.  This leads to all
sorts of odd behavior for the user.

By having everything either completely work or completely fail, it gives a
cleaner experience for the user.

> does it need double cpu/bandwidth to use the udp socket to communicate

The setup cost isn't so much in creating UDP sockets, it's in conducting the
connection process.  In the worst case of symmetric NATs, this can involve
doing a probabilistic port-scan of the remote host.  Thus setting up one
connection between two peers could conceivably involve hundreds of packets
going back and forth over many seconds time.

> security, one-port approach is indeed as sweet as you love to suggest.

Heh, I guess what I meant is I'd like my beloved approach to be recognized
as a valid and encouraged option, but by no means the only option.

-david