Current street prices for US Internet Transit

Wed Aug 18 05:41:07 UTC 2004

> 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
> leeway.

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.

DJ