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

[David Fifield <david () bamsoftware com>]

On Wed, Sep 05, 2007 at 04:14:25PM -0700, Fyodor wrote:
> 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.

There is a limit in slow start mode--it's the congestion threshold.
(Although that may be scaling a bit too abruptly--see the occasional
spikes in the graphs.)

There's no limit in congestion avoidance mode, though that's a good
idea. Here are statistics for 1/packet_ratio in the 10,000-host test:

Min.   : 17.29  
1st Qu.: 51.19  
Median : 58.84  
Mean   : 57.04  
3rd Qu.: 63.30  
Max.   :105.00

So 50 is probably safe. I'll add that.

David Fifield

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