Re: New development in host discovery: response rate scaled congestion control

[David Fifield <david () bamsoftware com>]

On Thu, Sep 06, 2007 at 04:58:20AM +0000, Brandon Enright wrote:
> I did 2 rounds of testing, 4 scans per round.  The first was done with
> r5786 and the second with r5788.
>
> Here are the test results for round 1:
>
> 64-64: (david_new_2a.svg)
> # Nmap done at Thu Sep  6 01:31:57 2007 -- 186368 IP addresses (10602 hosts
> up) scanned in 5013.688 seconds
>
> 64-2048: (david_new_2b.svg)
> # Nmap done at Thu Sep  6 01:16:10 2007 -- 186368 IP addresses (7656 hosts
> up) scanned in 4066.421 seconds
>
> 2048-2048: david_new_2c.svg)
> # Nmap done at Thu Sep  6 01:16:10 2007 -- 186368 IP addresses (7656 hosts
> up) scanned in 4066.421 seconds
>
> NOMIN-NOMAX (just -T5): david_new_2d.svg)
> # Nmap done at Thu Sep  6 01:47:37 2007 -- 186368 IP addresses (8972 hosts
> up) scanned in 5943.742 seconds

You said that you ran all the scans at the same time. This new technique
ought to approximate TCP congestion control more closely--if four
concurrent Nmaps are run, each one should run about 1/4 as fast.

That's the best explanation I can think of. Otherwise, your 2048-2048
result doesn't jibe with the one from a few days ago:

> Nmap done: 186368 IP addresses (15804 hosts up) scanned in 258.023 seconds
>                Raw packets sent: 1398404 (55.937MB) | Rcvd: 51659 (2.426MB)

The effect of both the scaled congestion control and the additional drop
processing should be negligible with such a large minimum parallelism.
The difference in time should not be that great.

All of the Nmaps are sharing the bandwidth, except that the 2048-2048
guy is unfairly blasting the network. That's causing the other scans to
slow down and drop packets.

Please run the NOMIN-NOMAX scan all by itself. And then the 2048-2048
scan by itself, just as a sanity check. If the time is again over about
500 seconds, then I must have changed something I didn't intend to.

The only other possibility I can think of is that the additional drop
processing is slowing it down. I had previously ignored dropped ICMP
destination unreachables; those are no longer ignored because I thought
the scaled congestion control would more than make up for the drops. If
the above tests don't give favorable results, please try again with the
attached patch (it's just the reverse of r5780). Ignoring those drops
was something of a compromise to begin with. I think not ignoring them
is more correct.

Thanks again for your dedicated testing.

> I can't explain these results.  I've generated graphs these scans in case
> those will be helpful at all.  I removed the y axis limit of 80 before
> generating these.  The graphs are located at:
>
> http://noh.ucsd.edu/~bmenrigh/nmap/

Thanks, those help. (The SVG is good because I can stretch them out and
get higher resolution.) Although they all looked to be capped at 80, so
for the 2048-2048 scans the black line was clipped completely (not even
present in the XML file).

David Fifield

Attachment: drops.diff
Description:

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