Date: Fri, 7 Sep 2001 04:20:27 -0700 (PDT)
From: Michael Thomas <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Er, the flow key is src/dst/flowlabel, right? That means it's
| 64k per host pair which seems like plenty.
Sure, as far as identifying the flow is concerned. I guess I was thinking
more of a usage model .. that is, src/dst/flowlabel is 272 bits (16 bit
label), that's a hell of a huge database lookup key - to actually be used,
(as a hash table lookup key for example) it needs to be reduced to some
reasonable size.
Doing that the "normal way" (value modulo some prime) seems like it would be
a much too expensive operation to contemplate. Doing it by calculating some
kind of CRC of the 272 bits, then using however many bits of that would be
better, but still not blindingly cheap.
What's left is the "use N of the M bits, ignore the rest" (where "ignore"
doesn't mean we don't compare them with the result of the has lookup).
If we do that, then which N? Clearly if the flow label is a PRNG, those
bits, or as many of them as are needed, would be a good choice. If there
are insufficient of those bits (and I suspect 16 isn't enough) then more
bits are needed. Some kind of guessing game could be done with picking
extra bits out of the addresses (xoring the two, ...) but those bits, while
often seemingly random, aren't - and they're clearly not going to be as good
as having more PRNG bits would be.
That's what I was getting at.
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
