On 12/16/2011 11:03 PM, Mark Andrews wrote: >> Well, that's assuming the queries are really fragmented into more than >> one packet. Is there any data about this? (i.e., size of requests) > > It's the state on the sending side I'm worried about. You are > adding ~13K entries a second to the destination cache it will > soon get large as *every* DNS/UDP response has a fragmentation > header.
Well, the problem you mention with the destinations cache is not really introduced by this algorithm -- the Destinations Cache is there anyway (it is not created because of this). If the Destinations Cache gets too big, you prune part of the entries, and then the worst thing that can happen is that when the Fragment ID is reinitialized with a random number for a future communication instance, there's a Fragment ID collision, and the corresponding fragments get discarded. However,since the Identification field of the IPv6 Fragment Header is much larger than that of IPv4, I'd argue that collisions are rather unlikely (for instance, the reason for which we're proposing the algorithm we¿re proposing rather than simply randomizing the Fragment ID for each packet is to avoid collisions when two systems are transferring a lot of data, at a high rate.... since in those scenarios, and with the ever increasing data rates, there might be collisions) > Instead of maintainin a counter on a per-destination basis, hash > the source and destination and use a pool of fragment counters > possibly using differently seeded lsfr. FWIW, Linux and Solaris have already implemented this algorithm. IIRC, an earlier version of this document proposed something along the lines of what you mention. But IIRC we abandonded the idea because implementers were concerned about computing a hash for each outgoing packet. That aside, one should be careful with the approach you're describing. Unless the number of counters is really large, then it wouldn't be hard to learn the current value of all counters -- after all, you have 64 bits in the Interface ID to play with, which could possibly let you learn the current value of all the "Fragment ID" counters (i.e., not as bad as a global counter, but still not good enough). All the above said, take this as "brainstorming"... if we conclude that it would be best to provide a number of alternative algorithms, or even change the currently recommended algorithm, I'd have no problems with that. (the current one is the result of discussions with the v6 developers of a number of OSes... but there's always room for improvement) Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
