Re: [aqm] New Version Notification for draft-baker-aqm-sfq-implementation-00.txt

On Tue, Jun 24, 2014 at 1:48 PM, Fred Baker (fred) <fred@cisco.com> wrote:
>
> On Jun 24, 2014, at 1:33 PM, Daniel Havey <dhavey@yahoo.com> wrote:
>
>> There may be scenarios where the interaction of the interval, the RTT and the bandwidth cause this to happen recurringly constantly underflowing the bandwidth.
>
> To be honest, the real concern is very long delay paths, and it applies to AQM algorithms generally. During TCP slow start (which is not particularly slow, but entertains contains exponential growth), we have an initial burst, which with TCP Offload Engines can, I’m told, spit 65K bytes out in the initial burst. The burst travels somewhere and results in a set of acks, which presumably arrive at the sender at approximately the rate the burst went through the bottleneck, but elicit a burst roughly twice as fast as the bottleneck. That happens again and again until either a loss/mark event is detected or cwnd hits ssthresh, at which point the growth of cwnd becomes linear.

I think tcp offloads have been thoroughly shown by now to blow up all
sorts of networks, and there has been a lot of work in recent linux
kernels for hosts to mitigate it (use smaller bursts), most recently
the sch_fq + pacing work. The objective of slow start is to "fill the
pipe" and especially in the case of long rtts like in satellite and
lte networks, it needs to be, well, slower.

tcp offloads are an assist to slower cpus and a per-ethernet-device
"feature" to get more "bandwidth" for less cpu... at the cost of
latency, bursty loss, and packet mixing. modern x86 hardware can
easily saturate gigE links without TSO in use at all. many lower end
(arm) products can't, as yet, and 10GigE is still the realm of TSO
(with mitigations arriving in software as per above)

I do hope things like TSO2 (bursts of 256k packets) are not widely
adopted, and smarter mixing happens on multi-queued ethernet devices
instead.

> If the burst is allowed to use the entire memory of the bottleneck system’s interface, it will very possibly approach the capacity of the bottleneck. However, with pretty much any AQM algorithm I’m aware of, the algorithm will sense an issue and drop or mark something, kicking the session into congestion avoidance relatively early.

big bursts are bad. let packets be packets!

Kicking things into congestion avoidance early turns out to have
interesting interactions with hystart.

>
> This is well-known behavior, and something we have a couple of RFCs on.
>
> But yes, it can happen on more nominal paths as well.
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article