On Wed, Apr 8, 2009 at 8:49 PM, Cullen Jennings <[email protected]> wrote: > > 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?
I've been thinking about whether there is any more accurate way to describe what the tests indicate. 4.3 currently uses the phrase "the NAT currently has Endpoint-Independent Mapping". It might be slightly more accurate to say that "the test produces no evidence to indicate that the NAT is not currently using Endpoint-Independent Mapping." Of course, given all of the requests to shorten the text, that's a lot of verbage to update all relevant statements. It's also going to be very hard to read. I can add another explanation to the beginning of Section 4, though. > Many of the NATs out there you > can not make this determination without multiple IP addresses behind the > NAT. So you're right that you can test for a few more bizarre NAT behaviors with multiple IP addresses, but I haven't seen any evidence suggesting those behaviors are present in most NATs. Obviously these tests (that require multiple private IP addresses) can't be run by most applications. I also think this is a good example of tests that can be run using the Attributes defined in behavior-discovery, but which really don't need to be described in the draft. Can you provide what you would think would be an appropriate reference? I'll add a statement that for more accurate characterization of NAT behavior, these tests must be run using multiple private IP addresses. Regardless of those tests, this is playing with the law of diminishing returns. Since NATs can change behavior over time and under load, focusing too much effort on characterizing a single instant in time isn't going to be nearly as useful as monitoring the NATs behavior under usage. > 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". Please cite any time when you have raised this objection at the mic in the minutes or audio recordings. I have no recollection of you doing this, and do not see it in the minutes. Henry did mention it in a comment at the mic once, which I did not respond to clearly, but I don't believe you have ever brought this up at the mic. The topic has been discussed offline, though, and I believe it is in the same category of the discussions about testing for linux NATs and for other bizarre behaviors that have been seen. The draft tries to discuss the most straightforward tests, in particular for describing behaviors according to rfc4787. It can't describe every test possible with the attributes, nor should it. But providing pointers to and encouraging readers to investigate other applications of the attributes seems like a good idea. > 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. I don't know what you're referring to here. For some reason your reply didn't go to the behave WG list, so I restored that to the CC list. This draft has been discussed in detail at 3 separate sessions, briefly at several others, and multiple times on the mailing list. If you think there is a topic that has not been adequately discussed on the mailing list, by all means bring it up. I welcome any WG comments on this topic. Bruce > > Cullen <as individual contributor> > > _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
