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

[Fyodor <fyodor () insecure org>]

On Wed, Sep 05, 2007 at 04:36:14PM -0600, David Fifield wrote:
> The idea is that whenever we make a change to the group congestion
> window, we scale the increment by the inverse of the packet receipt
> ratio; i.e., the ratio of the packets that have been responded to versus
> the number that have been sent. This makes the congestion window vary in
> a healthier manner, as it would with a TCP stream with a steady supply
> of responses coming in. More information and graphs are here:
>
>       http://www.bamsoftware.com/wiki/Nmap/ResponseRateScaledCongestionControl

Hi David.  That sounds like a great idea, and it is well presented on
the ResponseRateScaledCongestionControl page.

This scaling addresses the problem of the congestion window increasing
too slowly, but a possible problem is extrapolating too much data
based on one response.  If we have a 95% drop rate, then one response
is weighted such that it counts like 20.  That is OK, but what if we
have a 99.99% drop rate?  We don't want one response to act like
10,000.  So I think there should be a limit.  Maybe there already is
-- I haven't read your patch yet.  If I had to pick a limit out of the
air, I'd say that 50x is reasonable.  Though something different is OK
too if it works better.  If hitting that limit is causing problems,
then maybe we should use more of the confusingly named host discovery
pings, where we ping a known live host just to generating timing/drop
info.

Cheers,
-F

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