From owner-freebsd-net  Thu Feb  3 18: 2:20 2000
Delivered-To: freebsd-net@freebsd.org
Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11])
	by builder.freebsd.org (Postfix) with ESMTP id 6B8D53FD4
	for <freebsd-net@freebsd.org>; Thu,  3 Feb 2000 18:02:18 -0800 (PST)
Received: from brisbane.wrs.com (brisbane [147.11.38.9])
	by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA19916
	for <freebsd-net@freebsd.org>; Thu, 3 Feb 2000 18:02:12 -0800 (PST)
From: Stephen Macmanus <stephenm@windriver.com>
Received: (from stephenm@localhost)
	by brisbane.wrs.com (8.9.1/8.9.0) id SAA01528
	for freebsd-net@freebsd.org; Thu, 3 Feb 2000 18:02:30 -0800 (PST)
Date: Thu, 3 Feb 2000 18:02:30 -0800 (PST)
Message-Id: <200002040202.SAA01528@brisbane.wrs.com>
To: freebsd-net@freebsd.org
Subject: Path MTU discovery
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

         I have found some puzzling behavior in the path MTU discovery 
     implementation in Free BSD 3.4 which I hope someone can shed light
     on.

         The tcp_mtudisc routine adjusts the MSS for a connection in
     response to the ICMP error which triggers adjustment of the path
     MTU estimate to a new value. That routine includes the following
     code:

            struct tcpcb *tp = intotcpcb(inp);
            struct rtentry *rt;
            struct rmxp_tao *taop;
            struct socket *so = inp->inp_socket;
            int offered;
            int mss;

            if (tp) {
                    rt = tcp_rtlookup(inp);
                    if (!rt || !rt->rt_rmx.rmx_mtu) {
                            tp->t_maxopd = tp->t_maxseg = tcp_mssdflt;
                            return;
                    }
                    taop = rmx_taop(rt->rt_rmx);
                    offered = taop->tao_mssopt;
                    mss = rt->rt_rmx.rmx_mtu - sizeof(struct tcpiphdr);
                    if (offered)
                            mss = min(mss, offered);

                                  .
                                  .
                                  .

         Both this routine and the tcp_mss routine examine the results of
    tcp_rtlookup() to verify that a route to the destination address
    exists. That test appears to be redundant. I can't see a situation
    where the system is unable to find a route to the remote address
    given that the routine can only execute after the socket assigns
    local and remote address information, which includes the route lookup.

         Similarly, I don't entirely understand the conditional execution
    of the min() operation. It can only apply before the remote peer sends
    the initial SYN since tao_mssopt is always non-zero after that point.
    That could occur if the host generates the ICMP error by sending a TCP
    segment which includes data along with the SYN flag. Examining the 
    tcp_output() routine, that behavior doesn't seem possible. Does anyone
    know how it can occur?

                                                        Thanks,

                                                        Stephen

------------------
Stephen Macmanus                               #include <std_disclaimer.h>
Software Engineer
Wind River Systems                            


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message