On 12/4/2012 10:28 AM, Jose Saldana wrote:
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.
Such gaps are like per-packet overheads, which act like larger L2
headers, and can be accounted for that way.
Joe
Best regards,
Jose
-----Mensaje original-----
De: Joe Touch [mailto:[email protected]]
Enviado el: martes, 04 de diciembre de 2012 18:17
Para: [email protected]
CC: 'Matthew Ford'; 'Wesley Eddy'; [email protected]
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
