On Apr 5, 2009, at 8:57 PM, Bruce Lowekamp wrote:
Bernard, Thanks for the comments. Let me see if I can describe a scenario in which behavior-discovery is useful. First, we don't want to "go back to 3489." There were two problems (well, there were a lot more problems, but I just want to talk about two right now) in particular that we don't ever want to go back to: - 3489 specified that an application would start up, characterize its NAT, and work in that mode forever after - 3489 specified that if you had a friendly NAT, you could query the STUN server for your transport address and use that one address At the same time, behavior-discovery is targeting applications for which ICE doesn't necessarily make sense. For example, applications that don't want to fall back to TURN, but have other options for how to establish a connection. (whether this means indirect routing or not needing the connection, or other reasons) So let me try to go into more details on a potential P2P application. When P2P node A starts up, it evaluates its NAT(s) relative to other nodes already in the overlay. Let's say that its testing indicates it's behind a good NAT, with endpoint-independent mapping and filtering.
This is the where this whole line of thinking goes off the rails. How would we run a test that would indicate the above? Many of the NATs out there you can not make this determination without multiple IP addresses behind the NAT. I have raised this objection at the microphone multiple times in the WG and it is always meant with roughly the same answer that is here "ah, there are some details that are in the draft but we can explain how to do it in the next version of the draft". The draft is now in IETF LC and we have not seen details on how to do this that work even in an opportunistic way. The WG has not even had a chance to comment on if the believe these details would work or not.
Cullen <as individual contributor> _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf