On Tue, Jun 24, 2014 at 1:48 PM, Fred Baker (fred) <[email protected]> wrote: > > On Jun 24, 2014, at 1:33 PM, Daniel Havey <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
