On Mon, 3 Mar 2008, Fernando Gont wrote:
(Shame on me... somehow you mail got stuck in my queue, and I didn't respond
to it).
No sweat, I've taken far longer to reply to your e-mails!
While I haven't look match at the scheme proposed by Amit, I think there's a
"flaw" with the algorithm: IP IDs need to be unique for {source IP, des IP,
Protocol}. And the algorithm still keeps a *global* IP ID. That means you'll
cycle through the whole IP ID space when you probably didn't need to.
That is true. I think we have a time/space tradeoff here, with Amit's
algorithm taking more memory and less time than a hash-based algorithm.
But I haven't benchmarked one against the other, so it is possible that a
double-hash might win in both categories.
I think Robert Watson said something about investigating the issue of IP
IDs more in the near future. What I'd like to see (if possible) is that
we use Amit's algorithm until we've established a connection with a host,
then switch to per-IP state and just use linear IP IDs. That would seem
to provide the least overhead for high speed connections.
That said, at least theoretically speaking, one could argue that there
shouldn't be a problem with simply randomizing the IP ID number. For
connection-oriented protocols, you should be doing PMTUD, and thus will not
care about the IP ID. If your packets are doing fragmentation, then on links
will large bandwidth-delay products you're already in trouble. For
connection-less transport protocols (e.g., UDP), while they usually do not
implement PMTUD, they also do not implement flow-control or congestion
control. So you are either sending data to a local system (e.g., in a LAN),
or you probably shouldn't be sending data that fast (and then you shouldn't
have problems with trivially randomizing the IP ID).
I have attempted to make that argument before, and it did not go over well
with most people. :)
I think the counter-argument was primarily centered around UDP NFS, which,
as you pointed out, is almost always a losing case.
The double-hash concept sounds pretty good, but there's a major problem
with it. If an application does a bind() to get a local port before doing
a connect(), you don't know the remote IP or the remote port.
Yes, this is described in Section 3.5 of our id
(http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt).
Our take is that in that scenario you could simply randomize the local port.
(i.e., implement the double-hash scheme, and fall-back to trivial
randomization when you face this scenario).
Doh, I will try to read the ENTIRE paper next time before commenting.
There's a related "feature" in the BSD TCP stack that all local ports are
considered equal; even for applications that do a connect() call and
specify a remote IP/port, we do not let them use the same local port to two
different remote IPs at the same time. This puts a limit on the total
number of outgoing connections that one machine can have.
mmm... I see. So this could limit the number of outgoing connections to about
(ephemeral_ports/TIME_WAIT). Any objections against changing this? At least
for outgoing connections (i.e., non-listening sockets), this shouldn't be the
case. I'd be interested in working on this issue...
I don't think anyone is actively working on that problem, so you won't be
stepping on anyone's toes by looking into it. Bring on the patches!
There's a piece of low hanging fruit also in that area - we add incoming
connections to the local port hash table, even though it seems unlikely
that you are going to receive a connection from 1.1.1.1:50000->1.1.1.2:80
and then connect from 1.1.1.2:80->1.1.1.1:50000. Those unnecessary
additions to the local port hash time would be nice to remove if you're
investigating the related issues.
One thing you may or may not have noticed is that FreeBSD keeps TIME_WAIT
sockets in a seperate zone which has a limit size, so you will not have to
worry too much about them clogging up all ephemeral ports.
-Mike
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
