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:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.