[net-perf] bad performance w/o jumbo frames over large BDPs

[Jeff W. Boote]

Michael Sinatra wrote:
> If you need high BDP testers, there's a bunch of us out here. :)
> 
> Re, the question of whether it makes sense to use such an old kernel: If 
> we're mainly interested in testing the *network* with the Abilene nms 
> infrastructure, then it doesn't really matter what the test nodes use as 
> their kernel/OS, as long as it can push line-rate.  OTOH, what most of 
> us are doing is testing both the network and the end hosts (particularly 
> tuning of the end hosts), and for that it might make sense to have a 
> host in the infrastructure that is likely to be similar to what would be 
> on the other end that we are trying to talk to.  It may be possible 
> (although unlikely) that there are differences in optimal tuning based 
> on what the other host is doing.  The reason I think that may be 
> unlikely is that tuning the congestion control algorithm is basically a 
> sender-side issue and tuning the window is basically a receiver-side 
> issue.  But who knows?
> 
> In other words, if we're just interested in making sure there's no 
> packet loss on the abilene backbone, then it doesn't matter what the 
> nodes use, as long as they do RFC-compliant TCP, so that they're 
> approximating the type of production traffic that we would be sending. 
> But, if you wanted to provide an infrastructure that helps end sites 
> optimally tune their machines, then it *might* be good to use something 
> similar to what end-sites are using.

In general, I agree. We want to model the users experience. The difficult part 
is that we have to pick our 'typical' user to do that. In the abilene obs 
measurements, what I would say we strive for is "the canary in the coal mine". 
We want our measurement tests to be fairly fragile so we notice network problems 
before others.

For example, we use Reno congestion control on purpose. We tune it properly so 
it *can* achieve good performance, but we want it at least as fragile as what we 
expect the majority of our users to be using. In general - upgrading less 
frequently is a good match for this. (Why would Linux developers want to make 
their TCP less robust in the next version? This of course does not account for 
mistakes...)

In any case, I agree that currently it would be beneficial for us to have a more 
current release on our hosts. The reality of life for us is that we can only 
muster the resources to do full upgrades of our measurement hosts about once 
every 1-1.5 years. And, we don't tend to install the leading edge stuff when we 
do. Stability is a more important criteria - our hosts are not easy for us to 
get to, so we have to be careful. (And, since these systems are basically 
End-Of-Life'd, we will not be putting additional resources into them. We install 
the first few new-network POPs in the next 6 weeks.)

jeff