Thanks, Joe. Another limitation to take into account is the number of packets per second that the buffer is able to send. Sometimes there is a gap between small packets, since there is a minimum time between packets.
Best regards, Jose > -----Mensaje original----- > De: Joe Touch [mailto:to...@isi.edu] > Enviado el: martes, 04 de diciembre de 2012 18:17 > Para: jsald...@unizar.es > CC: 'Matthew Ford'; 'Wesley Eddy'; tsv-area@ietf.org > Asunto: Re: AQM work in the IETF > > > > On 12/4/2012 1:07 AM, 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. > > This depends on whether the resources are byte-based or packet-based. > > Byte-based examples include bandwidth (when supporting variable-sized > frames at L2), encryption/authentication of the entire packet, and memory > (using variable-sized buffers). > > Packet-based include header processing overheads, fixed-frame network > capacity, and fixed-size buffers. > > How different traffic reacts to limited resources depends on how these > resources are implemented, and which resources are limited/constrained. > There's no single answer based solely on traffic. > > Joe
