On Thu, 16 Dec 2010, Jan Engelhardt wrote:
On Thursday 2010-12-16 10:57, Jesper Dangaard Brouer wrote:
[...] NetConf 2010, see:
http://vger.kernel.org/netconf2010.html
I just went over a few slide sets, and noticed Dave's Netfilter summary
about your IPTV talk, enlisting the point
* Ethernet switches buffer too small
("too small".. "too few"?) Given the recent uproar about bufferbloat in
routing devices (see LWN coverage about Getty's articles), wanting
larger buffers seems to almost contradict what Getty would like.
Always wanting small buffers doesn't make sense. It seem that he is not
considering that network equipment can be used for other things than
TCP/IP.
What I want is a *smooth* IPTV multicast signal (which thus consumes
minimal buffer space), but because the streamers are bursting packets, I
want large enough buffers in the switch, to handle these bursts.
What I recommend (in the backbone) is to increase the buffer size in the
QoS queue, which is used for e.g. IPTV/multicast. And have another queue
for the normal Internet traffic (because too large buffers can cause
issues).
Though TV is usually delivered via UDP rather than TCP, some of the
protocols may too implement some sort of congestion recognition or
even avoidance technique ÿÿ IIRC realplayer had something that
adapted video quality based upon transfer rate.
Our TV streamer send out a MULTICAST signal, thus there is NOT any
congestion feedback...
Wanting more buffers vs. wanting less buffering seems to be quite
contradictory. Jesper, what is your take on this?
Skimming through Getty's blog post, I think Getty has actually missed what
is happening. He should read my masters thesis[1]... The real problem is
that TCP/IP is clocked by the ACK packets, and on asymetric links (like
ADSL and DOCSIS), the ACK packets are simply comming downstream too fast
on the larger downstream link, resulting in bursts and high-latency on the
upstream link.
With the ADSL-optimizer I actually solved Gettys problem, but I guess the
real solution would be to implement a TCP algorithm which handels this
asymmtry, and e.g. isn't based on the ACK feedback...
[1] http://www.adsl-optimizer.dk/thesis/
Cheers,
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
