There is a phrase in this thread that is begging to bother me. "Throughput". Everyone assumes that throughput is a big goal - and it certainly is - and latency is also a big goal - and it certainly is - but by specifying what you want from "throughput" as a compromise with latency is not the right thing...
If what you want is actually "high speed in-order packet delivery" - say, for example a movie, or a video conference, youtube, or a video conference - excessive latency with high throughput, really, really makes in-order packet delivery at high speed tough. You eventually lose a packet, and you have to wait a really long time until a replacement arrives. Stuart and I showed that at last ietf. And you get the classic "buffering" song playing.... low latency makes recovery from a loss in an in-order stream much, much faster. Honestly, for most applications on the web, what you want is high speed in-order packet delivery, not "bulk throughput". There is a whole class of apps (bittorrent, file transfer) that don't need that, and we have protocols for those.... On Tue, May 27, 2014 at 2:19 PM, David Lang <da...@lang.hm> wrote: > the problem is that paths change, they mix traffic from streams, and in > other ways the utilization of the links can change radically in a short > amount of time. > > If you try to limit things to exactly the ballistic throughput, you are not > going to be able to exactly maintain this state, you are either going to > overshoot (too much traffic, requiring dropping packets to maintain your > minimal buffer), or you are going to undershoot (too little traffic and your > connection is idle) > > Since you can't predict all the competing traffic throughout the Internet, > if you want to maximize throughput, you want to buffer as much as you can > tolerate for latency reasons. For most apps, this is more than enough to > cause problems for other connections. > > David Lang > > > On Mon, 26 May 2014, David P. Reed wrote: > >> Codel and PIE are excellent first steps... but I don't think they are the >> best eventual approach. I want to see them deployed ASAP in CMTS' s and >> server load balancing networks... it would be a disaster to not deploy the >> far better option we have today immediately at the point of most leverage. >> The best is the enemy of the good. >> >> But, the community needs to learn once and for all that throughput and >> latency do not trade off. We can in principle get far better latency while >> maintaining high throughput.... and we need to start thinking about that. >> That means that the framing of the issue as AQM is counterproductive. >> >> On May 26, 2014, Mikael Abrahamsson <swm...@swm.pp.se> wrote: >>> >>> On Mon, 26 May 2014, dpr...@reed.com wrote: >>> >>>> I would look to queue minimization rather than "queue management" >>> >>> (which >>>> >>>> implied queues are often long) as a goal, and think harder about the >>>> end-to-end problem of minimizing total end-to-end queueing delay >>> >>> while >>>> >>>> maximizing throughput. >>> >>> >>> As far as I can tell, this is exactly what CODEL and PIE tries to do. >>> They >>> try to find a decent tradeoff between having queues to make sure the >>> pipe >>> is filled, and not making these queues big enough to seriously affect >>> interactive performance. >>> >>> The latter part looks like what LEDBAT does? >>> <http://tools.ietf.org/html/rfc6817> >>> >>> Or are you thinking about something else? >> >> >> -- Sent from my Android device with K-@ Mail. Please excuse my brevity. > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel