Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast & Onvoy

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Fri Aug 3 02:33:04 UTC 2007


On Thu, 02 Aug 2007 18:33:16 PDT, Jim Shankland said:

> Hmm; I've never actually heard of anybody doing PMTUD on non-TCP
> traffic, though it's possible.  Does anybody actually do it?

AIX 5.2 and earlier supported it for UDP (we're getting out of the AIX
business, so I can't speak to what 5.3 does).  Basically, it would send out a
gratuitous 64K ICMP Echo Request with DF set, and waited to see what came back.
 I ended up turning it off all over, simply because we didn't have enough
UDP-based services that actually hit frag issues to make a difference.

---
'man no' (Network Options) says:

no { -a | -d Attribute | -o Attribute [ =NewValue ] }

udp_pmtu_discover Enables or disables path MTU discovery for UDP applications.
UDP applications must be specifically written to utilize path MTU discovery. A
value of 0 disables the feature, while a value of 1 enables it. This attribute
only applies to AIX 4.2.1 or later. udp_pmtu_discover is a runtime attribute. In
versions prior to AIX 4.3.3, the default value is 0 (disabled); in AIX 4.3.3 and
later versions, the default value is 1 (enabled).
---

The manpage lies - It has to be specifically written to *benefit from* PMTUD.
It would go ahead and do it, and then 98% of the UDP programs wouldn't change
their behavior.  So all you got was lots of gratuitous ICMP mobygrams.

It *may* have made a small difference during a short window, when NFS-over-TCP
support was still rare, and the 4500-octet FDDI MTU was sometimes to be found.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070802/db5f2af2/attachment.sig>


More information about the NANOG mailing list