Re: [nmap-svn] r6963 - nmap-exp/david/nmap-fixed-rate

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 21 Mar 2008 17:03:48 -0700
David via commit-mailer () insecure org wrote:

> Author: david
> Date: Fri Mar 21 17:03:48 2008
> New Revision: 6963
>
> Modified:
>    nmap-exp/david/nmap-fixed-rate/scan_engine.cc
>
> Log:
> Remove the code that "catches up" the next scheduled send time. It
> turns out it's beneficial to let this lag a bit to compensate for
> delays elsewhere in the code, like the pcap reads. If the scan engine
> can send enough probes it can catch up itself.
>
> This becomes a problem, though, at higher packet rates, when the next
> scheduled send time falls behind faster than it can catch up (the
> actual number of packets sent falls farther and farther behind the
> expected number of packets sent). This gives the scan engine license
> to blast tons of packets in a vain attempt to catch up. While it's
> sending, incoming packets are dropped, causing a flood of
> retransmissions, which in turn leaves even less time to listen for
> incoming packets. This means that the actual packet per second can
> decrease as the requested packets per second increases, once past a
> certain threshold. This will be addressed in a forthcoming commit.

Hi David,

This behavior is not at all uncommon for networking applications that
try to send packets as fast as possible.  Unicornscan and many other
applications exhibit this behavior.

The best thing I've come across for trying to avoid this thrashing is
to simplify the packet scheduler _as_much_as_possible_.  The more logic
trying to decide if a packet should be sent or not, the more time is
wasted not sending the packet.

I'm sure you have a plan for how to take care of the problem and I
haven't looked at your modifications but you might try a "best effort"
algorithm that enforces a reasonable minimum delay between packets so
that if it ends up trying to "catch up" it wont thrash itself into
falling farther behind.  You really want to send packets at
min(desired, thrashing threshold).

If you want to determine that threshold you might try something like
TCP window scaling to slowly ramp up to the desired rate while
carefully trying to detect diminishing marginal returns on the real
rate.

I look forward to the end-result, sometime sending at N pps is exactly
what I want Nmap to do.

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFH5FK1qaGPzAsl94IRAsVaAJ4r058RVpw3tsv2/eCJDFprJgf+SACfSIva
IymLEm0HBUN2y3uNl/z75h0=
=LCIq
-----END PGP SIGNATURE-----

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