Subject: [P2PSIP] comment on draft-marocco-p2psip-xpp-00

From: Bryan Ford <[email-masked]>
Date: Fri, 13 Jul 2007 10:25:03 +0200

Dear Enrico and Emil,

I happened to be browsing through your draft-marocco-p2psip- 
xpp-00.txt, and noticed your statement in section 1.1:

    It is true that the definition of three-way TCP [RFC0793] handshake,
    also provides semantics that could be used for simultaneous
    connection establishment; however, this mechanism is defined for
    resolving race conditions and is not meant for use as a common
    practice.  Such a mechanism is likely to only work in certain
    situations (i.e. when both peers are located behind NATs).  In a  
case
    where both endpoints have public addresses and are able to
    communicate directly, any attempt to simultaneously establish a
    connection will almost always fail as the reception of a first SYN
    request would usually trigger an RST response before the application
    has had the chance of sending a second corresponding SYN.

This statement is incorrect, and seems to be a common misconception  
regarding TCP nat traversal.  As long as the applications on both  
endpoints first bind a listen socket to the TCP port they will use  
before starting the hole punching process (via outgoing connect  
sockets from the same ports), and as long as the OS implements the  
TCP state machine correctly (which all major OSes do now, the only  
known recent exception being Windows XP before SP2), the applications  
will connect reliably in the no-NAT case with no spurious RSTs.  The  
only potential problem with spurious RSTs occurs if there *are* NATs  
on the path, and at least one of them is "poorly behaved".  For  
details, see for example my p2p-over-NAT paper from USENIX 2005  
(http://www.brynosaurus.com/pub/net/p2pnat/).

UDP still may be a better choice than TCP for a protocol that wants  
to traverse NATs, just because more existing NATs in the wild are  
already NAT traversal friendly for UDP than for TCP (see the same  
paper for example, or Guha and Francis's more detailed analysis of  
specific NATs).  So you don't need the incorrect statement above to  
motivate your work anyway.

I see this Internet-Draft is a bit old, so apologies if this error  
has already been pointed out.

Cheers,
Bryan

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 13 Jul 2007 12:35:56 +0200

Bryan Ford wrote:
> Dear Enrico and Emil,
> 
> I happened to be browsing through your draft-marocco-p2psip-xpp-00.txt,
> and noticed your statement in section 1.1:
> 
>    situations (i.e. when both peers are located behind NATs).  In a case
> before starting the hole punching process (via outgoing connect sockets
> from the same ports), and as long as the OS implements the TCP state
> machine correctly (which all major OSes do now, the only known recent
> exception being Windows XP before SP2), the applications will connect
> reliably in the no-NAT case with no spurious RSTs.  The only potential
> problem with spurious RSTs occurs if there *are* NATs on the path, and
> at least one of them is "poorly behaved".  For details, see for example
> my p2p-over-NAT paper from USENIX 2005
> UDP still may be a better choice than TCP for a protocol that wants to
> traverse NATs, just because more existing NATs in the wild are already
> NAT traversal friendly for UDP than for TCP (see the same paper for
> example, or Guha and Francis's more detailed analysis of specific
> NATs).  So you don't need the incorrect statement above to motivate your
> work anyway.

Yep, Bryan, you are right.  SO_REUSEADDR socket option can be used to
open a socket in listen state on a port which can later be bound by
another socket for connecting, and this would prevent the OS to answer
RSTs to SYNs.  Thank you for pointing out the bogus statement, we'll fix it.

-- 
Ciao,
Enrico

---

From: Emil Ivov <[email-masked]>
Date: Sat, 14 Jul 2007 00:01:39 +0200

Hey Bryan,

(inline)

Enrico Marocco wrote:
>> <snip>...</snip>
>> reliably in the no-NAT case with no spurious RSTs.  

Good point. Actually I was already having doubts about this after I saw
a related discussion on MMUSIC. You are of course right, and this will
when both peers are public.

Still, the whole thing is quite tricky to implement and obliges
developers to follow routines that they shouldn't be required to care
about. In order to have this working for two sockets one has to:

Instead of simply opening a socket, a programmer would have to have at
least two of them. Then declaration , initilization (setsockopt),
binding, connecting and accepting a connection for these 2sockets have
to be executed in a strict order. And in the end, before the connection
is established, you are manipulating the different socket instances
without knowing which one you are actually going to be using.

Even if we get APIs that do this transparently for the programmer, it'll
still mean an extra layer and a number of abstractions that are being
used without a good reason.

It does make sense to have such techniques used in ICE-TCP, so that they
could be employed for existing solutions when necessary, but we should
keep in mind that this is a workaround (not a design choice), and
probably something that would be best to avoid relying on when
standardizing new protocols.

I think you are also making a similar point in your paper, and I guess
we need to mention this in the draft.

> The only potential

Thanks for the tip! We'll make sure it gets in xpp's next version.

Cheers
Emil