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

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 27 Nov 2006 05:50:18 -0800 (PST)

Jonathan,

Thank you for reviewing the document. Please find my responses inline.

regards,
suresh

--- Jonathan Rosenberg <[email-masked]> wrote:

> 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.
> 
[suresh] Can you provide specifc examples of where the context is not adequate.
Thanks.

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

[suresh] Section 4 was meant precisely for that. If you are refering to
specific things missing, do let us know. Thanks.

> 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.
> 
[suresh] For the purposes of this document, we did not need all the granular
definitions in the udp document. SO, we explain the terms used and state how
they relate to the UDP terms. The explantions do not hurt the understanding.

> 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.
> 
[suresh] You are right. However, if the NAT is not p2p-friendly, the server is
unable to notify the public node which endpoint to expect the connection from
for node-A. I will fix the text accordingly.

> > 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]"
> 
[suresh]Right. I will fix that.

> >  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?
> 
[suresh]Right.

> >  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.
> 
[suresh] Agreed. I will excise the recommendation text. 

Thank you for your comments.

regards,
suresh

> 
> Thanks,
> Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> _______________________________________________
> Ietf-behave mailing list
> [email-masked]
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 

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