[dvblast-devel] Jumbo Frames

[Andy Gatward]

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.

Andy.