Re: Path MTU and beacon
On Wed, 09 Feb 2005 17:17:38 +0100
Jean-Jacques Pansiot <pansiot@crc.u-strasbg.fr> wrote:
> 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.)
Note : I meant that some writers mean that their "data" MTU does not include the RTP overhead.
> >
> >
> Yes this was my conclusion
ACK
>
> >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
Got you. However, this is the beacon, which can go who knows where. An MTU should be chosen to
maximize the probability of working globally.
Remember, many I1 ISP's still use overlay networks for multicast. Other networks (I1 or I2) are
likely to drop fragmented packets entirely.
>
> >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)
Well, what's in the code ?
>
> What about using Path-MTU discovery ?
>
Unlikely to be useful or supported, alas :(
>
> Jean-Jacques
Marshall
>
> >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
> >>
> >>
> >>
> >>
> >
> >
> >
>