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 >
