AS701/Verizon

Tue Mar 12 11:58:30 UTC 2019

> From: NANOG <nanog-bounces at nanog.org> 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