RE: Home media servers, AUPs, and upstream bandwidth utilization.
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. :-) 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.
On Tue, 26 Dec 2006 09:07:10 -0800 Joe St Sauver <joe@oregon.uoregon.edu> wrote:
But that's all host-based -- what about at the network level?
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
On Dec 26, 2006, at 12:12 PM, John Kristoff wrote:
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.
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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice All battles are perpetual. -- Milton Friedman
participants (3)
-
Joe St Sauver -
John Kristoff -
Roland Dobbins