Re: End System PMTUD behavior question

er.Hunt@nokia.com writes:
> Hemant,
> =20
> Forgive me if I've misunderstood, but it sounds like you're saying that =
> we should require protocols or applications above IP to always send data =
> in messages small enough to avoid IP fragemntation.
> =20
> I agree it makes sense for a higher layer to use the PMTU information in =
> IP's cache when it can. Expecting TCP to use the PMTU is perfectly =
> reasonable, as it's already chopping up a byte stream into packets. For =
> protocols which are already packetized, though, I think it's less =
> advantageous to burden them (or the application using them) with the =
> problem of fragmentation and reassembly, to avoid IP fragmentation.
> =20
> For example, if a user does a "ping -s 1500" to a destination whose PMTU =
> is 1280, the only way to avoid IP fragmentation is for the ping =
> application to split the data into multiple messages, or for IPCMPv6 to =
> do so. Either way, you have to introduce some way to identify them as =
> "ping fragments" and reassemble them in order. That will require changes =
> to the ICMPv6 protocol, I think. Furthermore, you're no longer really =
> doing a "ping 1500", but two pings of 1280 and 220 bytes, respectively.
> =20
> In the case of an application which sends records in single UDP frames, =
> to avoid fragmentation is must split its messages into MTU-sized =
> chuncks, and come up with a way at the destination to identify and =
> reassemble the chunks in order. This seems a bit unreasonable, given =
> that IPv6 has a perfectly good mechanism to do this already.
> =20

	For the record.  DNS servers just tell the kernel to fragment
	at network mtu for UDP/IPv6 and ensure that DF is off for
	UDP/IPv4.

	DNS clients don't usually generate packets big enough to
	be a issue.  If they do need to send a big (> 512) message
	they usually just switch straight to TCP to avoid having
	to probe the server to see how big a UDP message it will
	handle.

> So I think the behaviour observed by Thomas during his testing is =
> correct. I don't think ping or ICMPv6 should reduce the ICMP message =
> size to avoid IP fragmentation.
> =20
> Peter Hunt
> Software Engineer
> Nokia S&S.
> =20
> 
> ------_=_NextPart_001_01C97CEC.C9F8E0DD
> Content-Type: text/html;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> 
> <HTML dir=3Dltr><HEAD><TITLE>RE: End System PMTUD behavior =
> question</TITLE>=0A=
> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
> <META content=3D"MSHTML 6.00.6001.18183" name=3DGENERATOR></HEAD>=0A=
> <BODY>=0A=
> <DIV id=3DidOWAReplyText26585 dir=3Dltr>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#000000 =
> size=3D2>Hemant,</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>Forgive me if I've =
> misunderstood, but it sounds like you're saying that we should require =
> protocols or applications above IP to always send data in messages small =
> enough to avoid IP fragemntation.</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>I agree it makes =
> sense for a higher layer to use the PMTU information in IP's cache when =
> it can. Expecting TCP to use the PMTU is perfectly reasonable, as it's =
> already chopping up a byte stream into packets. For protocols which are =
> already packetized, though, I think it's less advantageous to burden =
> them (or the application using them) with the problem of fragmentation =
> and reassembly, to avoid IP fragmentation.</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>For example, if a =
> user does a "ping -s 1500" to a destination whose PMTU is 1280, the only =
> way to avoid IP fragmentation is for the ping application to split the =
> data into multiple messages, or for IPCMPv6 to do so. Either way, you =
> have to introduce some way to identify them as "ping fragments" and =
> reassemble them in order. That will require changes to the ICMPv6 =
> protocol, I think.&nbsp;Furthermore,&nbsp;you're no longer really doing =
> a "ping 1500", but two pings of 1280 and 220 bytes, =
> respectively.</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>In the case of an =
> application which sends records in single UDP frames, to avoid =
> fragmentation is must split its messages into MTU-sized chuncks, and =
> come up with a way at the destination to identify and reassemble the =
> chunks in order. This seems a bit unreasonable, given that IPv6 has a =
> perfectly good mechanism to do this already.</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>So I think the =
> behaviour observed by Thomas during his testing is correct. I don't =
> think ping or ICMPv6 should reduce the ICMP message size to avoid IP =
> fragmentation.</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>Peter =
> Hunt</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>Software =
> Engineer</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT face=3D"Courier New" size=3D2>Nokia =
> S&amp;S.</FONT></DIV>=0A=
> <DIV dir=3Dltr><FONT size=3D2></FONT>&nbsp;</DIV></DIV></BODY></HTML>
> ------_=_NextPart_001_01C97CEC.C9F8E0DD--
> 
> --===============0174434914==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> --===============0174434914==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------