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.
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).
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
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 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].
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.
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 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.