|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Current street prices for US Internet Transit
That's entirely a different example. If we are talking about a stream that is _exactly 5Gb/s or _exactly_ 5mb/s, the policer won't be hit. In the example we are talking about below, an _approximately_ 5Gb/s stream on an _approximately_ full pipe the performance will be significantly better than you imply. And I have customers that do it pretty regularly (2 ~500Mb/s streams per GE port - telemetry data) on their equipment with very small buffers (3550s).Have you tried running a single TCP stream over a 10 meg ethernet with a 5 megabit/s policer on the port? Do that, figure about what happens and explain to the rest of the class why this single TCP stream cannot use all of the 5 megabit/s itself. Yes, if you are trying to fill your pipe for more than a few miliseconds and are schooling your GSR/Juniper to drop or prevent queuing beyond say 50ms, that might be a useful improvement. Not that anyone does that....I'm implying that a 7600 with non-OSM doesn't have more than a few ms of buffers making a single highspeed TCP stream go into saw-tooth performance mode via it's congestion mechanism being triggered by packet loss instead of via change in RTT. Yes, the GSR/juniper with often 500+ ms buffers are often of no use in todays world, but it's nice to have 25ms buffers anyway, so TCP has some leeway. I suppose your example of transoceanic connectivity vs an 80km span was an example where a congestion case would exist for a long time rather than a decent upgrade plan. I guess that is a spend more on HW vs spend more on connectivity model -- or trust that C or J overengineered so the network doesn't have to be properly engineered [by assumption]. Agreed. I guess it depends where you want to spend your engineering dollars. If your interfaces are pretty small and subject to bursting to wirespeed often and they somehow make it into your core [and are not dropped by your aggregation gear with its smaller buffers] then you can queue it.If you have thousands of TCP streams it doesn't matter, then small packet buffers will simply act as a high-speed policer when the port goes full and they'll be able to fill the pipe together anyway. If you run a network where your bursts disappear by the time they hit your core [either because of statistical aggregation or simply being dropped by the smaller interface buffers along the way] or you have ample capacity or you have engineered properly sized core trunks, its not an issue. I hope most fall into this category, but I could be wrong. DJ
|