[e2e] using p2p overlays to overcome recursive NATs/realms

Jonathan Rosenberg jdrosen at dynamicsoft.com
Fri Feb 8 09:14:04 PST 2002


"David P. Reed" wrote:
> 
> Man do I hate NATs.  I'm prototyping a really neat collaborative
> real-time
> platform that really wants UDP packets that are not connection-like at
> all
> (yes, I've got some interesting ideas for adaptation that allows the
> ensemble to respond helpfully to congestion - in fact, theoretically you
> 
> should be able to manage congestion better by coordinated ensemble
> action
> than by pairwise-independent TCP-like cong.ctrl. - another thesis topic
> for
> the grad student iconoclast).
> 
> Most NATs handle UDP as if it is TCP-like.  That is, if you as party A
> are
> behind the NAT, the mapping works such that you can't send a packet out
> to
> party  B which has a UDP port that will work for parties C, D, ... to
> send
> a packet back to you.  THis is one of the problems that was pointed out
> in
> the original NAT RFC, back when NATs were being proposed as a serious
> alternative to V6.
> 
> But UDP wasn't developed for pair-wise connections like this.  It was
> developed so that apps that don't have a sensible notion of pairwise
> connections can work.
> 
> Yes I can and will do "overlay" level UDP routing as a workaround, but
> that
> is wrong, because it creates special nodes that cannot fail, or a need
> for
> highly dynamic overlay routing that can cope with loss of individual
> "overlay routers".  If you are building a scalable system that creates a
> 
> shared environment for thousands of peers, you don't want to have to
> create
> a special class of fixed overlay routers.

I'm a bit late on this thread, so my apologies if someone has already
mentioned how stun can help here.

Depending on the type of nat, stun
(http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt)
doesn't require an overlay network at all. In the case of most
residential nats in particular, they are more permissive for incoming
UDP packets than in the case of TCP (i.e., it need not be symmetrical).
STUN allows you to discover the nat type and then figure out what your
address is on the other side. The server is not in any packet processing
paths at all; they are stateless servers that can be anywhere on the
Internet, there is no impact on packet routing if you use one server as
opposed to another.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen at dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com



More information about the end2end-interest mailing list