netdev - Re: IPTV buffering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.1012211634330.21593@ask.diku.dk>
Date:	Tue, 21 Dec 2010 17:24:23 +0100 (CET)
From:	Jesper Dangaard Brouer <hawk@...u.dk>
To:	Jan Engelhardt <jengelh@...ozas.de>
Cc:	Netfilter Developer Mailing List 
	<netfilter-devel@...r.kernel.org>, netdev <netdev@...r.kernel.org>
Subject: Re: IPTV buffering 

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
-------------------------------------------------------------------