> From: NANOG <[email protected]> On Behalf Of Saku Ytti > Sent: Tuesday, March 12, 2019 7:58 AM > > PSA to people running transit networks. > > a) During congestion you are not buffering just the exceeding traffic, you > will > delay every packet in the class for duration of congestion > b) Adding buffering does not increase RX rate during persistent congestion, it > only increases delay > c) Occasional persistent congestion is normal, because how we've modeled > economics of transit > d) Typical device transit network operates can add >100ms latency on a single > link, but you don't want more than 5ms latency on BB link > > Fix for IOS-XR: > class BE > bandwidth percent 50 > queue-limit 5 ms > > Fix for Junos: > BE { > transmit-rate percent 50; > buffer-size temporal 5k; > } > > > The actual byte value programmed is interface_rate * percent_share * time. > If your class is by design out-of-contract, that means your rate is actually > higher, which means the programmed buffer byte value results in smaller > queueing delay. The configured byte value will only result in configured > queueing delay when actual rate == g-rate. > > The buffers are not large to facilitate buffering single queue for 100ms, the > buffers are large to support configurations of large amount of logical > interfaces each with large number of queues. If you are configuring just few > queues, assumption is that you are dimensoning your buffer sizes. > > Hopefully this motivates some networks to limit buffer sizes. > > Thanks! > +1 to that. The overall system works so much better if the network nodes don't interfere and instead report the actual network conditions accurately and in a timely fashion to the end hosts -i.e. by inducing drops as and when they occur. There are a number of papers on this topic btw..
adam
