NetBSD Problem Report #55788

From www@netbsd.org  Thu Nov  5 14:41:45 2020
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 12EA41A9246
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  5 Nov 2020 14:41:45 +0000 (UTC)
Message-Id: <20201105144144.009E31A9259@mollari.NetBSD.org>
Date: Thu,  5 Nov 2020 14:41:43 +0000 (UTC)
From: uwe@stderr.spb.ru
Reply-To: uwe@stderr.spb.ru
To: gnats-bugs@NetBSD.org
Subject: tcp(4): TCP_MAXSEG documentation is out of date
X-Send-Pr-Version: www-1.0

>Number:         55788
>Category:       misc
>Synopsis:       tcp(4): TCP_MAXSEG documentation is out of date
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    misc-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Nov 05 14:45:00 +0000 2020
>Originator:     Valery Ushakov
>Release:        NetBSD-current as of 2020-11-05
>Organization:
>Environment:
>Description:
tcp(4) says:

TCP_MAXSEG     By default, a sender- and receiver-TCP will negotiate
               among themselves to determine the maximum segment size
               to be used for each connection.  The TCP_MAXSEG option
               allows the user to determine the result of this
               negotiation, and to reduce it if desired.

However Stevens begins discussion of this option with:

  Some texts refer to this as a "negotiated" option. It is not
  negotiated in any way. When a connection is established, each end
  has the option of announcing the MSS it expects to receive.

and  RFC879:

  The MSS can be used completely independently in each direction of
  data flow.


That was fixed with this initial commit by thorpej@ (plus some
followups):

Fix several annoyances related to MSS handling in BSD TCP:
- Don't overload t_maxseg.  Previous behavior was to set it to the min
  of the peer's advertised MSS, our advertised MSS, and tcp_mssdflt
  (for non-local networks).  This breaks PMTU discovery running on
  either host.  Instead, remember the MSS we advertise, and use it
  as appropriate (in silly window avoidance).
- Per last bullet, split tcp_mss() into several functions for handling
  MSS (ours and peer's), and performing various tasks when a connection
  becomes ESTABLISHED.
- Introduce a new function, tcp_segsize(), which computes the max size
  for every segment transmitted in tcp_output().  This will eventually
  be used to hook in PMTU discovery.

sys/netinet/tcp_var.h - revision 1.23
date: 1997-09-23 01:50:04 +0400;  author: thorpej;  state: Exp;  lines: +12 -3;

sys/netinet/tcp_subr.c - revision 1.28
date: 1997-09-23 01:50:02 +0400;  author: thorpej;  state: Exp;  lines: +176 -1;

sys/netinet/tcp_input.c - revision 1.32
date: 1997-09-23 01:49:55 +0400;  author: thorpej;  state: Exp;  lines: +17 -166;

sys/netinet/tcp_output.c - revision 1.17
date: 1997-09-23 01:49:59 +0400;  author: thorpej;  state: Exp;  lines: +44 -14;

PS: Documentation for TCP_MAXSEG never calls "MSS" by its name, which
is much more widely known than the option name, making it harder to
find.


>How-To-Repeat:
man tcp, search for MAXSEG
>Fix:

Home	PR Database Search