RE: Home media servers, AUPs, and upstream bandwidth utilization.

Mailman List Mirror (Read Only)
1

Chris mentioned:

#it might also be interesting to know how tcp-stack differences affect some
#of the usage patterns as well. With the now widely deployed win* platform
#tcp stach respecting tcp-reno things work according to well
#understood/accepted models. Mac OSX, linux and Vista seem to NOT respect
#tcp-reno, and may change the models somewhat... Will this cause more
#spikiness on individual links? will this change in behaviour on a wide
#scale (vista rollout to new computers or to existing platforms) causing
#folks capacity planning models to fail?

Capacity planning is a very important issue, but for other folks capacity
*under*utilization is the flip side of that issue. For example, there are
still scientific researchers who continue to be puzzled by low throughput
for bulk data transfers, even with clean fast ethernet (or gig ethernet!)
connections end-to-end. For example, looking at table 1 of

   http://netflow.internet2.edu/weekly/20061218/

we can see that on I2 95% of all bulk TCP data transfers are ~25Mbps or
less -- however the top 1/10th of 1% successfully demonstrate 1Gbps
throughput.

The question then becomes one of "How do we help bridge that 'wizard
gap' or transfer that expertise (of those who are demonstrably able to
fully utilize the connections at their disposal) to all the other
well-connected researchers out there?"

Things like Web100, see

   http://www.web100.org/download/

are intended to help automate this for Linux users, although clearly
there are still issues with applications (if you're curious, you
can see the sort of improvements to SSH that were made by the folks
at PSC at:

   http://www.psc.edu/networking/projects/hpn-ssh/

and there's a lot of fascinating empirical work that's been done with
applications such as GridFTP (where encryption is not the bottleneck).

So what about Vista? Well, it has (or should have, I'll withold any final
assertions until I see what actually finally gets shipped to consumers)
a number of TCP performance enhancements which are described at
http://www.microsoft.com/technet/community/columns/cableguy/cg1105.mspx
(last updated September 22nd, 2006). If the network traffic load feels
different post-Vista, well, it very well may *be* different. :slight_smile:

But that's all host-based -- what about at the network level?

I'm intrigued to see things like jumbo frames accounting for a non-negligible
fraction of traffic on Internet2 (e.g., roughly 7% or so of octets, see
http://netflow.internet2.edu/weekly/longit/perc-b-jumbo-packets.png ),
and I also notice that at least one alternative TCP/IP implementation
has elected to commercialize in the form of a 1U gateway appliance that
does its mojo network wide, rather than working to retrofit individual
hosts with high performance TCP stacks on a host-by-host basis.

I think those sort of things have tremendous potential to change the
aggregate network behavior we all see over time.

Regards,

Joe St Sauver (joe@uoregon.edu)
http://www.uoregon.edu/~joe/
Disclaimer: all opinions strictly my own.

2

Hi Joe,

There are also the widely deployed "packet shaper" boxes that are
artificially reducing throughput, including in some instances on the
path between Abilene connected networks and their end hosts. I've run
into this myself as you may recall me eluding to recently. This may
be another good excuse for doing the report card.

In some cases there is has also been no easy away around them even when
the institution realizes that their placement is less than ideal for
cases that are not the popular peer-to-peer music sharing (which is
clearly the application these boxes were initially targetting to slow
down).

I'm not very excited about things like jumbo frames, in part because
of the good work you did there to show hard they are to actually get
end-to-end, but all it takes these days is for one middle box in the
path to cripple, in any myriad of ways, an end host stack optimization.

John

3

Jumbo frames can certainly be helpful within the IDC, for example between front-end systems and back-end database and/or storage systems; the IDC is also a more controlled and predictable environment (or at least it should be, heh) than the aggregate of multiple transit/access networks, and therefore in most cases one ought to be able to ensure that jumbo frames are supported end-to-end between the relevant IDC-hosted systems (or even between multiple IDCs within the same SP network). This isn't the same as a true end-to-end capability between any discrete set of nodes on the Internet, but they can still indirectly increased performance for a topologically diverse user population by virtue of more optimal throughput 'behind the curtains', as it were.