[dvblast-devel] Jumbo Frames

[Georgi Chorbadzhiyski]

On 13.3.2012 г. 09:44, Andy Gatward wrote:
> On 12/03/2012 22:43, "Georgi Chorbadzhiyski"<gf at unixsol.org>  wrote:
>
>> Forgot to mention, since we are talking udp here. If the software that
>> reads this output stream do not expect to get more than 1316 bytes (why
>> should it expect that?) and issues reads for 1316 bytes (which is pretty
>> standard for mpegts over udp), this means everything after 1316 bytes up
>> to the size of the packet you set will be probably lost. So while the MTU
>> parameter probably will work and DVBlast will try to send bigger packets,
>> expect only problems.
>
> The MTU parameter was added for a couple of reasons.  On IPv6 networks we
> have to assume an MTU of 1280 bytes (the minimum specified in the various
> RFCs) as we have no means of doing path MTU discovery on multicast; and
> also for people using DVBlast for point-to-point distribution over IPSEC
> VPN or some non-Ethernet links, 1500 is a dangerous assumption.   If we're
> using RTP on IPv4, generally we're sending 1,336 byte packets (7 x
> 188-byte MPEG-TS packets + 12 bytes RTP header + 8 bytes UDP header) -
> this doesn't fit in GRE over IPSEC over xDSL with some providers.  We
> weren't expecting to use jumbo frames, in fact this is potentially
> dangerous as if a frame is lost or corrupted you are losing a larger
> section of your transport stream.

Thanks Andy, exactly my point. Using /mtu= to decrease MTU - fine,
increasing it, not so much. It'll send bigger frames but 99% of programs
just read up 1316 (in case of udp multicast), and the rest will be lost.
Which reminds me that I have to fix some of my own software :)

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/