On 4/16/14, 10:25 AM, "Dave Taht" <[email protected]> wrote:
>On Wed, Apr 16, 2014 at 8:28 AM, Greg White <[email protected]> wrote: >> >> I agree with others that reducing the web model to a single 700kB file >> download is unrealistic. Also, for recent work we've increased the >>object >> sizes to correspond to a projected 2018 page size (extrapolating from >> http://httparchive.org/trends.php) of about 7MB. > >While the trendline is impressively "up": > >http://httparchive.org/trends.php?s=All&minlabel=Nov+15+2010&maxlabel=Apr+ >1+2014 > >I'm reluctant to do a linear extrapolation of that trendline from 3 >years of data. Perhaps >a longer term store, like that of archive.org, could be explored. I'm >not one to predict >a "Peak Web", but the idea of a typical web page load cracking 7MB in >5 years disturbs >me. > >> >> For our 2018 model of Internet traffic (again, upstream focused) where >>the > >I do like, very much, trying to come up with projections for what traffic >will >look like in 5 years. I'll ask around... Yes, it would be interesting to get some other views on this. >> T: number of torrent (LEDBAT) connections > >Torrent does not behave as per your model; I just had a long meeting >with brahm over that. Presently per "new" torrent you typically see >dozens of >sessions "connected", but only 6 or so sessions exchanging data in >both directions, >with a new connection explored and rotated to every 15 seconds or so. > >After a file is fully transferred, the same logic remains, but upload >only. >Anticipating that a given site would have 16 simultaneous torrents over >a 100 active connections being redistributed seems overlarge, and I >imagine >that a typical number is bound much lower by the bittorrent software. 6 sessions * 16 torrents seems to end up pretty close to 100 total sessions. Am I missing something? I neglected to mention that the torrent traffic is limited to 50% of the user's upstream data rate, based on evidence (like you suggest) that torrent clients by default limit their traffic, and it is apparently well known that running it unlimited is not recommended (probably due partly to bufferbloat, but once established, the mindset might still remain even after bufferbloat is eliminated). >> *Filesize and repetition pattern chosen to exercise DOCSIS "powerboost" >> feature > >Yes, I'd like not only to have that but to actually have running code in >linux that could emulate it... :) The code we've released for the ns2 model is available if you want to use that as a start. Or, I can walk you through the math if you'd rather. >> Since evaluation comes before deployment (by a long lead time in some >> cases), and, once deployed, algorithms may have a long life, I would >> encourage the AQM Evaluation Guidelines draft to consider not just what >> traffic looks like historically, but what we can reasonably predict for >>the >> future. > >+1 > >Now that we are transporting hi resolution video, voice, web, and data >in addition to the traditional email and chat, I have great difficulty >assuming >that bandwidth demands will continue to grow as they have, as the new >stuff >is mostly "fixed" in its bandwidth needs, rather than dynamic like tcp. > >... Unless someone comes up with a way of encapsulating other senses or >some application that truly demands high bandwidth that can work at >multiple RTTs. Yes, I hear you and don't disagree. On the other hand it is hard to argue strongly against 30+ years of rock-solid consistent 50% annual increase... Plus, I'm probably not the only one who can remember at one point thinking "I'll never fill a 20 MB hard drive, why, that's 20 *million* bytes!" >There is a lot downward pressure to "do more with less", for example, >as with things like webrtc that are bundled in the browser and don't >require a lot of javascript support, and a lot of caching of core code >that takes place, and a lot of work in reducing RTTs in new protocols >like QUIC. > >(but I freely admit I could be wrong and would love to work on projections > that make sense!) _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
