On Wed, Apr 8, 2009 at 8:49 PM, Cullen Jennings <fluffy(_at_)cisco(_dot_)com>
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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf