Date: Fri, 04 Jan 2002 21:15:11 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Leo Bicknell <bicknell@ufp.org> Cc: William Carrel <william.carrel@infospace.com>, Terry Lambert <tlambert2@mindspring.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: path_mtu_discovery Message-ID: <200201050215.g052FB791341@whizzo.transsys.com> In-Reply-To: Your message of "Fri, 04 Jan 2002 18:56:22 EST." <20020104235622.GA53844@ussenterprise.ufp.org> References: <3C36149B.B9C02DCF@mindspring.com> <C64F7C2E-0159-11D6-9ED7-003065B4E0E8@infospace.com> <20020104235622.GA53844@ussenterprise.ufp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I don't have the RFC handy, but aren't all Internet connected hosts > required to support a minimum MTU of 576 from end to end with no > fragmentation? Thus if we ever got an MTU less than 576 we should > ignore it. Right? No, all hosts are required to be able to reassemble IP datagram fragments of at least 576 bytes, but there's no lower bound on the MTU of the interface. Small MTUs first appeared on low-bandwidth SLIP links. Along with TCP header compression, this put a lower-bound on how long you'd have to wait for a single packet to be transmitted on the interface. If your network interface was clever, and looked at the TOS bits in the header or peeked at the TCP port numbers, you could arrange to queue interactive traffic (telnet, rlogin, now ssh) ahead of non-interactive traffic (FTP, SMTP, etc.) to improve the perceived response time with remote character echos. If the MTU was large, a large FTP packet might just be starting its way out the interface when you want to transmit interactive traffic; the small MTU limits the pain. (Digression: NORTEL (at least) had an interesting encapsulation on their multiservice frame relay switch trunks where they could interrupt a packet being transmitted and insert delay sensitive traffic in the middle of a larger packet. Cool hack.) Also, even though this is on a cloned route, someone could attack "well known" routes that might be on your computer. For instance, the route to well-known recursive name servers on a network, which are pretty easy to guess for dial-up users on a modem pool. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201050215.g052FB791341>