Subject: [Ietf-behave] comments on draft-ietf-behave-p2p-state

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 7 Nov 2006 02:04:50 -0600 (CST) (envelope-from [email-masked])

A high level comment - the document needs some additional context to 
explain the role of the "server" in each of the different approaches, 
there to facilitate rendezvous.

Also, it would be great to include references or discussions of what 
existing p2p applications are actually using each technique.

I'm glad to see the document use the new terms from the behave-udp 
document. However I don't see why the document needs to restate and 
re-explain those definitions in section 2.

The table of contents is missing page numbers.

Section 3.2, you say that connection reversal only works if one side is 
public and the other is behind a p2p-friendly nat. I don't see why the 
latter is required; you are not relying on the Nat to allocate the same 
ip address and port for this to work.

the load on the initial introduction server S.  The application does
   not need to attempt to detect the kind of NAT device it is behind, 
   if any [STUN], since the procedure above will establish peer-to-peer

I think you mean, "as in [STUN]"

 by themselves, as well as their addresses as observed by S.  The
   clients then simultaneously start sending packets to each other at
   each of the alternative addresses they know about, and use the first
   address that leads to successful communication.  If the two clients
   are behind the same NAT, then the packets directed to their private
   addresses are likely to arrive first, resulting in a direct
   communication channel not involving the NAT.

That need not be the case; packet loss and other things can make this 
ordering reversed.

Is "first come first served" really what is being used?

 Dependent Mapping. For all of these reasons, it is NOT recommended
   that new applications implement this trick. This technique is
   mentioned here only for historical and informational purposes.

I agree with the sentiment; but if this is an informational document, 
making recommendations on techniques to use (or not) seems out of scope.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com