Desired --max-rate behavior: exceed the maximum to keep up the average?

[David Fifield <david () bamsoftware com>]

Hi list,

A few days ago I added a --max-rate option, complementary to --min-rate.
I hadn't announced it yet because I can't decide how it should act in a
certain situation, and I want your advice.

Implementing --max-rate is easy. If someone asks for --max-rate 100,
just ensure that no two probes are sent closer than 1/100 s apart. In
other words, if it's been less than 1/100 since the last probe sent,
don't allow sending another. This is basically what the current code
does. It works in most situations and slower send rates.

However such a technique means that if the sending rate is ever to equal
the maximum rate, it must send a packet every 1/100 s, without fail. If
one or more time slices are skipped because of congestion control or
pcap delays, there is no way to catch up. If 10% of the slices are
missed, the rate will be at 90% of maximum, even if Nmap is sending at
the maximum rate all the rest of the time.

Here is an example.
        nmap -n -PN -d3 -p- localhost
        Overall sending rates: 4237.11 packets / s, 186432.74 bytes / s.
So the scan appears to support 4000+ packets per second. Then 2000
should be no problem.
        nmap -n -PN -d3 -p- --max-rate 2000 localhost
        Overall sending rates: 756.26 packets / s, 33275.44 bytes / s.

This is easily explained by what I noted above, however, it is
surprising behavior.

The only solution I see is to allow the engine to go faster than the
maximum during the sending times to make up for the delays.
        ./nmap-nonstrict -n -PN -d3 -p- --max-rate 2000 localhost
        Overall sending rates: 1999.92 packets / s, 87996.43 bytes / s.
My problem with this solution is that it uses a very loose definition of
the word "maximum." It makes good sense from the user's perspective but
it hides the fact that the sending rate jumped to above 7000 packets per
seconds for very brief moments.

A variation on this is to allow only a certain number of "catch up"
packets, or to reduce the amount of packets allowed to catch up by a
certain fraction with each packet sent, keeping it in some reasonable
bounds. This "damped" behavior is implemented in the
/nmap-exp/david/nmap-fixed-rate branch. Here is some output:
        ./nmap-damped -n -PN -d3 -p- --max-rate 2000 localhost
        Overall sending rates: 1980.08 packets / s, 87123.43 bytes / s.
That's with damping of 1% applied to the number of catch-up probes. It
doesn't get to catch up completely, but it gets pretty close. However,
this approach appears to burst to over 10000 probes per second, for
reasons I don't understand.

What do you think is the right behavior? Should --max-rate be strict or
lenient?

David

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org