From owner-freebsd-bugs Fri Mar 8 12:36:39 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA10799 for bugs-outgoing; Fri, 8 Mar 1996 12:36:39 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [204.156.134.254]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA10793 for ; Fri, 8 Mar 1996 12:36:30 -0800 (PST) Received: (dillon@localhost) by apollo.backplane.com (8.6.12/8.6.5) id MAA02429; Fri, 8 Mar 1996 12:36:15 -0800 Date: Fri, 8 Mar 1996 12:36:15 -0800 From: Matthew Dillon Message-Id: <199603082036.MAA02429@apollo.backplane.com> To: "Garrett A. Wollman" Cc: bugs@freebsd.org Subject: Re: bug in netinet/tcp_input.c Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk :> If you do not *use* that field when calculating :> the mss you send to the other side for outgoing connections, what :> use is it? : :You use it to keep track of the MTU along the path from your host to :the other end. The purpose is to avoid fragmentation, not to allow :users to play games with maximum segment size. : :> For example, if you attempt to streamline TCP operation to a given :> destination by, say, setting the mtu to 296 and setting the recvpipe :> and sendpipe to, say, 768, the expected result only works in one :> direction... : :Which is precisely as it is intended. If you want to control the size :of packets sent by the other end, you have to control the other end! :That's the way TCP is designed to work. If you don't like it, design :your own protocol. Hmmm. Then what is the use of -recvpipe and -sendpipe ? It seems ridiculous to not give one the ability to adjust the remote MSS for a tcp connection. If the path mtu is being stored in the mtu field, perhaps what is needed is a new field to specify the maximum advertised mss. Without being able to do that, -recvpipe and -sendpipe are useless parameters for tuning purposes, and only being able to set the mss for our end asymetrically is even worse then useless. It's sooo close to doing something real, stop using 'the way TCP is designed to work' as an excuse! -Matt :-GAWollman : :-- :Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... :wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. :Opinions not those of| It is a bond more powerful than absence. We like people :MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant : Matthew Dillon Engineering, BEST Internet Communications, Inc. [always include a portion of the original email in any response!]