Hi, Since you mention byte vs. packet based queues: the effect of using one or the other can indeed be quite interesting. I'd like to throw this paper into the mix:
Lawrence Stewart, David Hayes, Grenville Armitage, Michael Welzl, Andreas Petlund: "Multimedia-unfriendly TCP Congestion Control and Home Gateway Queue Management", ACM Multimedia Systems Conference (MMSys 2011), 23-25 February 2011, San Jose, California, USA. Cheers, Michael On 4. des. 2012, at 10:07, Jose Saldana wrote: > Hi all. I am following the discussion about buffers and AQM, so here go my 2 > cents: > > In our research group in the University of Zaragoza, we have studied the > effect of different buffer policies on some services, mainly real-time ones > based on UDP (VoIP and networked games), when competing with other traffic. > We have also calculated the results in terms of subjective quality > estimators. > > Although we have not used AQM, we have used different FIFO buffer > implementations: > > - Buffer measured in bytes > - Buffer measured in number of packets > - Time-limited buffer > > A summary of some of the conclusions: > > - In general, big buffers are bad for real-time traffic (of course). > - If the buffer is measured in bytes, it is better for real-time services: > they use small packets, and the drop probability is higher for big packets. > - If the buffer is measured in packets, logically drop probability is the > same for every packet. > - Bufferbloat: Very big buffers make it impossible to use real-time > services, when there is congestion. The added delays become unacceptable. > > Four papers about the question (you can find them in > http://diec.unizar.es/~jsaldana/personal/index.htm): > > - "The Effect of Router Buffer Size on Subjective Gaming Quality Estimators > based on Delay and Jitter", IEEE CCNC 2012 > - "Influence of Online Games Traffic Multiplexing and Router Buffer on > Subjective Quality", IEEE CCNC 2012 > - "Evaluating the Influence of Multiplexing Schemes and Buffer > Implementation on Perceived VoIP Conversation Quality," Computer Networks > (Elsevier), 2012 > > If this work can be of any help, it would be perfect. As you see, we "like" > studying buffers, so we could perhaps do some research studies about > different AQM policies if necessary. > > Best regards, > > Jose > >> -----Mensaje original----- >> De: [email protected] [mailto:[email protected]] En >> nombre de Matthew Ford >> Enviado el: martes, 04 de diciembre de 2012 9:24 >> Para: Wesley Eddy >> CC: [email protected] >> Asunto: Re: AQM work in the IETF >> >> Hi Wes, >> >> Informed by a recent ISOC-hosted roundtable meeting (report is here: >> http://www.internetsociety.org/doc/bandwidth-management-internet- >> society-technology-roundtable-series) I have responses to some of your >> timely questions (speaking personally, of course): >> >> >> On 26 Nov 2012, at 06:56, Wesley Eddy <[email protected]> wrote: >> >>> Particularly, I have wondered: >>> - Should we have a working group looking at AQMs? >> >> I believe there is a strong and growing need for AQM at bottleneck links > and >> there is a need to document suitable algorithms and provide industry >> guidance (in the form of BCPs) regarding tuning, where that is a >> consideration, and applicability of particular mechanisms. But to get > beyond >> wishful thinking we need enough interest to produce a draft charter, at > least. >> >>> - If so, does it make sense to shoot for Standards Track >>> specifications? >> >> For promising and broadly supported algorithms, sure, why not? >> >>> - Would we be able to come up with actual requirements on an AQM so >>> that it's implementable for cheap in hardware and software, and >>> behaves well under load? >> >> I hope so, otherwise I think we have a pretty serious problem looming. >> >>> - Would it be valuable to have a test suite for AQMs similar to what >>> ICCRG was doing for high-rate TCP? >> >> I think this could be worth shooting for, although I can already imagine >> lengthy discussions about the validity and relative 'weight' of specific > tests. >> >>> - If any of this is of value, how much belongs in the ICCRG versus >>> TSV working groups? >> >> I tend to think this is valuable to the extent that it can be done in the > IETF >> rather than the IRTF. And I agree with Bob - most of the relevant > expertise is >> in TSV, although co-ordination with INT and OPS is certainly going to be >> important. >> >> Mat >> > >
