On Wed, Apr 8, 2009 at 8:49 PM, Cullen Jennings <fluffy@xxxxxxxxx> 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 todescribe what the tests indicate. 4.3 currently uses the phrase "theNAT currently has Endpoint-Independent Mapping". It might be slightlymore accurate to say that "the test produces no evidence to indicatethat the NAT is not currently using Endpoint-Independent Mapping." Ofcourse, given all of the requests to shorten the text, that's a lot ofverbage to update all relevant statements. It's also going to be veryhard to read. I can add another explanation to the beginning ofSection 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 behaviorswith multiple IP addresses, but I haven't seen any evidence suggestingthose behaviors are present in most NATs. Obviously these tests (thatrequire multiple private IP addresses) can't be run by mostapplications. I also think this is a good example of tests that canbe run using the Attributes defined in behavior-discovery, but whichreally don't need to be described in the draft. Can you provide whatyou would think would be an appropriate reference? I'll add astatement 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 diminishingreturns. Since NATs can change behavior over time and under load,focusing too much effort on characterizing a single instant in timeisn't going to be nearly as useful as monitoring the NATs behaviorunder 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 inthe minutes or audio recordings. I have no recollection of you doingthis, and do not see it in the minutes. Henry did mention it in acomment at the mic once, which I did not respond to clearly, but Idon't believe you have ever brought this up at the mic. The topic has been discussed offline, though, and I believe it is inthe same category of the discussions about testing for linux NATs andfor other bizarre behaviors that have been seen. The draft tries todiscuss the most straightforward tests, in particular for describingbehaviors according to rfc4787. It can't describe every test possiblewith the attributes, nor should it. But providing pointers to andencouraging readers to investigate other applications of theattributes 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 yourreply didn't go to the behave WG list, so I restored that to the CClist. This draft has been discussed in detail at 3 separate sessions,briefly at several others, and multiple times on the mailing list. Ifyou think there is a topic that has not been adequately discussed onthe mailing list, by all means bring it up. I welcome any WG commentson this topic. Bruce >> Cullen <as individual contributor>>>_______________________________________________Ietf mailing listIetf@xxxxxxxxxxxxx://www.ietf.org/mailman/listinfo/ietf