is/would this be a possible way to counter tcp syn floods

i imagine in a syn flood an attacker has a group of machines which they control with a remote control program. if they are smart all possible header fields are randomized. but i imagine each computer under the attackers control is located in different geographical locations, so the rtt varies. so if the attacker starts all of his zombies at the same time, they would actually start possibly seconds apart from each other. i imagine an attack program(the one installed on the zombie hosts) would just have a tight loop of header randomizing and sendto() calls. now what im wondering is:
*is it correct that when sending all these packets in a tight loop that there would be some function (like a sin wave or something?) that would approximate the time interval that the next packet would be sent?
*and if so, is the resolution on w/e clock is used to timestamp incoming packets good enuf to approximate that data accurately?

i think i have just confused myself, so hopefully someone understands what im trying to ask! basically, can you track a stream of packets to an originating host by using some sort of frequency function and then obviously start dropping packets that matched? i would imagine the clock resolution is a major factor b/c you need a very small window of time to minimize false positives. obviously it could be easily defeated by anyone with a brain, but imagine a lot of people who DOS dont have brains.

ps. i already posted this on comp.tcp-ip.(hopefully they dont flame my newbya$$), but i figured i would pick some of your genius brains as well

My opinion is that the network lag would make any attempt to recognize a pattern unreliable. Since most organizations that care the most about DDOS attacks are also ones that have massive bandwidth and super computer processing speeds, the actual arrival time of the syn packets would probably be effectively randomized by the network. You would also have a tremendous overhead in attempting to do pattern matching and it would be so easy to defeat. Just randomize the interval between sending each attack packet.

Besides, I think it would be easier programmatically to simply allocate a huge pile of RAM on a dedicated gateway machine and put some really short timeout (say a second or so) to drop the connection. As long as your connection buffer has enough space to handle all possible connection attempts in the timeout period you should be relatively safe.

yea that's what i was guessin, the network part. then i just thought now also, just b/c the call to send gets made, doesn't mean the packet has to go out. it could be queued for a random amount of time depending on what else the processor is doing i think.

fyi people told me to read about syn cookies.