On Wed, Dec 31, 2008 at 6:24 PM, William Herrin <[email protected]> wrote: > On Wed, Dec 31, 2008 at 5:27 PM, Christopher Morrow > <[email protected]> wrote: >> In 2005-ish at the IAB Workshop in AMS there was a good several >> presenations on scaling/growth (one by Tony Li about hardware and why >> moores-law doesn't apply to the gear in backbone networks). > > Chris, > > I think I read that one. It was right before dram bandwidth took a > sharp upward turn from something like 400mhz to I think 1600mhz today. > Prior to that, it exhibited less than half the rate of change, > increasing from 100 mhz in 1998 to 400 mhz in 2005. >
ah, then... perhaps tony can weigh in with a: "Yea, all good now" or "well, it's not quite as simple as that... + explanation?" ?? I was under the impression that DRAM wasn't the issue, but I'm fuzzy now as to the details. > >>> Assume a $2k COTS PC purchased 12/31/08 with component choice >>> optimized for routing. >> >> you can't make this assumption as 2k cots devices can't forward at >> +100gbps, a core backbone device today can, and do in several >> networks. > > Sure I can. My $2k COTS PC can route 500mbps easily. Packet switching sorry, of course you can make the assumption, I just don't think it follows as closely to reality as you'd want. that 500mbps isn't doing anything tough, with a small table, few interfaces, no services, no acls/filtering/qos ... consumer PC's just aren't a good correlary for backbone devices. > trivially parallelizes, so it follows that for no more than 200 times > the price I can move 200 times the packets. This doesn't tell me what > the actual cost would be, but it allows me to set an upper bound. > again, I don't think it follows that rational or simple a process/curve. However, if we wanted to say that 'today' we can buy a fully decked out 'backbone router' for 2m$/device, and yesterday it was 2.5M for the same device, and tomorrow it'll be 1.5M (and draw a set of curves for bw/pps/cost over time then sure... I'm not sure how accurate it'll be, or useful) > >>> Assume the ratio between BGP routes and updates per second will follow >>> whatever growth pattern has been demonstrated in the ratio of routes >>> to updates over the last 10 years. I expect this ratio is constant or >>> near constant. >> >> it's actually not constant, there are a number of factors > > Whatever it is, we should be able to plot points from years past on a > ratio to date graph and then fit a trend curve to it. > This I agree with, there is some trend, there should be some sort of function. To date, there hasn't been an effort (that I've seen) to fit a function to the plots vaf/huston have made from the route-table size data... I've not seen any useful 'rate of change' graphs since some of that is location dependent. Dave Meyer was talking, about 1.5 yrs ago, about trying to find funding to research the dynamics of the table change, I've not asked if that made headway. That does seem like what you want though, eh? > >>> How many routes can we pack in before we either fill memory, can no >>> longer sustain both the 500mbps routing rate and keep up with BGP >>> updates? Surely we can answer this question with engineering accuracy! >> >> One point Tony made was that soon, perhaps, you won't be able to make >> a lookup across the memory device holding the FIB fast enough to >> service a packet on the fastest known interfaces today, presuming the >> FIB grows in memory at some set rate (look at the graphs Vince Fuller >> or Geoff Huston have for approximations of the rates). > > If you can move packets across an interface at the given data rate > then you can blindly multiplex and demultiplex packets from and to > lower speed interfaces. This reduces the problem to one previously > solved. There's doubtless a better solution but for conceptual > purposes, that eliminates the data rate boundary condition as an > active factor in the scalability assessment. > out of order packets aren't a concern? filtering? qos? stream-size limits? at a gross level it might be comparable, but I'm not sure it helps cost a device that'll fit in a half-rack and push 1600gbps (T1600-juniper/ASR9k-cisco). -chris _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
