Re: Path MTU and beacon
Marshall Eubanks wrote:
>Most every Internet path involves an Ethernet at some point.
>Ethernet maximum frame size is 1514 bytes. (Gig-E is 9018 IIRC, but you still have to
>assume a 100 Base-T is likely somewhere.) However, 14 of these bytes
>are used by ethernet, leaving 1500 bytes for "data" - i.e., the Internet packet. One of the most
>common causes of multicast application problems I have seen is the confusion between
>the MTU for the IP packet, and the MTU for the data inside the packet. (Some code writers
>have their MTU include the IP + UDP packet overhead, some do not, some even don't include the RTP
>packet overhead, making confusion easy.)
>
>
Yes this was my conclusion
>However, there is another complication :
>Could there be a tunnel in your path ? IP in IP tunnels add 20 bytes or more (if there are shims).
>GRE adds 24 bytes.
>
>
I dont think there are special things in my path (I mean locally, since
"my path"
is in fact the mbone) since I receive IP fragments of size 1500 (ie
"normal" ethernet size).`
The problem is from sources sending packets of UDP size 1504 or 1508
>That means that a 1500 byte IP packet will fragment in a tunnel. I have even seen tunnels going
>through tunnels (ugh), but you have to draw the line somewhere. And there can be IPSEC tunnels and
>MPLS shims and who knows what else. And there are still lots of multicast tunnels out there.
>
>And, of course options set another complication, reducing things by another 4 bytes or more. Options
>are not supported on the general Internet, but you never know what someone might do on a tunnel.
>
>So, I prefer to set the _packet_ MTU in multicast to 1470 bytes or less. That means that the _data_
>overhead is 20 + 8 (for UDP) or 20 + 8 + 12 (including RTP), yielding 1442 for UDP and 1430 for UDP
>plus RTP.
>
>So, I think that the path MTU is set too high, and someone needs to look into just what is assumed
>in the parameter setting it in the code.
>
>
So you would recommend setting RTP_MAX_PACKET_LEN to 1442 (this
constant includes RTP headers)
What about using Path-MTU discovery ?
Jean-Jacques
>Regards
>Marshall Eubanks
>
>
>On Wed, 09 Feb 2005 14:33:22 +0100
> Jean-Jacques Pansiot <pansiot@crc.u-strasbg.fr> wrote:
>
>
>>Hello,
>>I have been experiencing with the beacon v1.1-0 for darwin,
>>using the default group *233.4.200.19*
>>My beacon sees only a fraction of all other beacons listed in the
>>central server
>>(say 6 or 10 among 80).
>>However, if I run ethereal, I observe that most, if not all, RTCP
>>packets I receive
>>are fragmented at the IP level : the UDP packets (including UDP header)
>>are 1504 or 1508
>>bytes and are splitted in 2 IP fragments (the first one being of size
>>1500 including IP header).
>>Since *233.4.200.19 *has many members, there is a tendancy to have RTCP
>>reports of the maximum size.
>>*
>>*On the other hand the file rtp.h (obtained with the beacon) indicates :
>>#define RTP_MAX_PACKET_LEN 1500
>>
>>which gives UDP packets of size 1500 + 8 , and IP packets of size 1500 +
>>8 + 20
>>Ět appears that this is too big for the Path-MTU of many networks, this
>>creates fragmentation
>>(and some firewalls filter IP fragments).
>>
>>Is it a known problem ? Should we consider lowering RTP_MAX_PACKET_LEN
>>to 1500 -28 ?
>>or even using Path MTU discovery ?
>>
>>
>>thanks
>>
>>Jean-Jacques Pansiot
>>
>>
>>
>>
>
>
>