IPTV buffering

IPTV buffering

[Jan Engelhardt]

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.

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.

Wanting more buffers vs. wanting less buffering seems to be quite 
contradictory. Jesper, what is your take on this?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IPTV buffering

[Jesper Dangaard Brouer]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2538 bytes --]


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

Buffer-bloat (was Re: IPTV buffering)

[Jesper Dangaard Brouer]

On Tue, 21 Dec 2010, Jesper Dangaard Brouer wrote:

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

I have created a blogpost:
  http://netoptimizer.blogspot.com/2010/12/buffer-bloat-calculations.html

Where I explain how it makes sense to have small buffers on links with a 
small bandwidth.

  - ISPs need to adjust the buffer size according to the bandwidth of the 
link.


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

Adjusting my statement; the asym ACK issue might be part the issue, 
causing the packets to queue in the buffer.

The buffer-bloat issue is very true and a real-life issue.  ISPs need to 
adjust the buffers according to the bandwidth on the link!

Cheers,
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------