Subject: Re: [BEHAVE] Announcing an IPv4 to IPv6 multicast translatorimplementation

From: "Tim Evens" <[email-masked]>
Date: Mon, 24 May 2010 16:06:42 -0400

-----Original Message-----
From: "Iljitsch van Beijnum" [[email-masked]]
Date: 05/21/2010 08:36 PM
To: "Teemu Kiviniemi" 

On 21 mei 2010, at 15:08, Teemu Kiviniemi wrote:
 
 >> (And why does Linux set DF on UDP by default, anyway?  It seems
 >> troublesome.)
 
 > The current defaults are bad. At least multicast should be sent with
 > path MTU discovery disabled by default.
 
As far as I know, there is no implementation of PMTUD for UDP over IPv4
anywhere. So you can't enable it, because it doesn't exist. Sending
non-TCP packets with DF=1 in the hopes that the application implements
PMTUD is like pushing people out of a plane under the assumption they
brought a parachute.

 <tievens>
"http://www.kernel.org/doc/man-pages/online/pages/man7/udp.7.html" details the following:

"By default, Linux UDP does path MTU (Maximum Transmission Unit) discovery.
       This means the kernel will keep track of the MTU to a specific target IP
       address and return EMSGSIZE when a UDP packet write exceeds it.  When this
       happens, the application should decrease the packet size.  Path MTU discovery
       can be also turned off using the IP_MTU_DISCOVER socket option or the
       /proc/sys/net/ipv4/ip_no_pmtu_disc file; see ip(7) for details.  When turned
       off, UDP will fragment outgoing UDP packets that exceed the interface MTU.
       However, disabling it is not recommended for performance and reliability
       reasons."
</tievens>
 
Separately from that, doing PMTUD for multicast, even assuming that an
application using UDP could arbitrarily reduce its packet size, which
is rarely if ever true, is a strange concept as there are multiple
receivers and the paths to the different receivers can easily have
different MTUs.
 
<tievens>
I
agree.   It'll be very tricky to implement PMTUD with multicast.  First
off, PMTU with multicast addresses as destinations is NOT supported at
least with Cisco IOS, which is a huge breakdown in expecting that to
work.  Secondly, this won't work within Layer 2 VPN's (MetroEthernet)
as the provider devices will not/can not respond.  Even if the devices
were to respond, one multicast sender could have hundreds if not
thousands of receivers.  Which receiver stream is the source/sender
supposed to accommodate by reducing the transmit packet size?  If all
receivers are fine with 1400 and then one straggler pops up with a MTU
of 500, does that mean the transmission immediately takes an abrupt
halt to switch payload sizes?  This also leads to another question as
to how will the source know that the receiver with a low MTU has left
and now the payload size can be increased?  It would suggest that a
periodic probe would be required.

</tievens>

---

From: Stig Venaas <[email-masked]>
Date: Mon, 24 May 2010 14:52:53 -0700

Tim Evens wrote:
[...]
> application using UDP could arbitrarily reduce its packet size, which is 
> rarely if ever true, is a strange concept as there are multiple 
> I agree.   It'll be very tricky to implement PMTUD with multicast.  
> First off, PMTU with multicast addresses as destinations is NOT 
> supported at least with Cisco IOS, which is a huge breakdown in 
> expecting that to work.  Secondly, this won't work within Layer 2 VPN's 
> (MetroEthernet) as the provider devices will not/can not respond.  Even 
> if the devices were to respond, one multicast sender could have hundreds 
> if not thousands of receivers.  Which receiver stream is the 
> source/sender supposed to accommodate by reducing the transmit packet 
> size?  If all receivers are fine with 1400 and then one straggler pops 
> up with a MTU of 500, does that mean the transmission immediately takes 
> an abrupt halt to switch payload sizes?  This also leads to another 
> question as to how will the source know that the receiver with a low MTU 
> has left and now the payload size can be increased?  It would suggest 
> that a periodic probe would be required.

For IPv6, multicast PMTUD is supposed to work (at least as I read the
RFCs), even if the concept is somewhat strange. You might say it's a
tree MTU rather than path MTU. So as receivers join or leave the group,
the tree MTU might change. One problem is of course as you say that one
straggler with MTU 500 can cause problems for everyone.

Yes, you would need periodic probing, but this is done for unicast as
well.

There are other interesting issues as well. If PMTUD is done for the
PIM-SM register tunnel, then you may lower the PMTU due to that one the
initial packet, and then when forwarding is done natively, you may keep
using a low PMTU for some time.

The best is probably to try to keep IPv6 multicast packets within 1280,
unless you have control of the path and know that the MTU is larger.

Stig

> </tievens>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 May 2010 09:21:25 +1000

In message <[email-masked]>, "Tim Evens" writes:
> To: "Teemu Kiviniemi" =
>  =
>  =
>  =
> non-TCP packets with DF=3D1 in the hopes that the application implements
> "http://www.kernel.org/doc/man-pages/online/pages/man7/udp.7.html" details t=
> he following:
> 
>              This means the kernel will keep track o=
> f the MTU to a specific target IP
>              address and return EMSGSIZE when a UDP =
> packet write exceeds it.   When this
>              happens, the application should decreas=
> e the packet size.   Path MTU discovery
>              can be also turned off using the IP_MTU=
> _DISCOVER socket option or the
>              /proc/sys/net/ipv4/ip_no_pmtu_disc file=
> ; see ip(7) for details.   When turned
>              off, UDP will fragment outgoing UDP pac=
> kets that exceed the interface MTU.
>              However, disabling it is not recommende=
> d for performance and reliability
>              reasons."
> </tievens>
>  =

	I'd love to see the Linux kernel developer's justification for
	failing to follow this part of RFC 1192.

	Mark

RFC 1192

   		    We do not want the IP layer to simply set the DF bit
   in every packet, since it is possible that a packetization layer,
   perhaps a UDP application outside the kernel, is unable to change its
   datagram size.  Protocols involving intentional fragmentation, while
   inelegant, are sometimes successful (NFS being the primary example),
   and we do not want to break such protocols.
 
>  =
> agree.     It'll be very tricky to implement PMTUD with multicast.=
>    First
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]