mawson@aldetec.oz.au (Graeme Mawson) (09/17/90)
We are presently experimenting with the TCP/IP protcol suite over an Ethernet LAN. A useful guide to TCP/IP by Comer seems to suggest that TCP segment size is user-definable. Is this true? Does anyone know how to define it? Any help will be gretly appreciated! Graeme Mawson. Aldetec Pty Ltd. -- Internet: mawson@aldetec.oz.au Perth, Western Australia.
mogul@wrl.dec.com (Jeffrey Mogul) (09/20/90)
In article <266@aldetec.oz.au> mawson@aldetec.oz.au (Graeme Mawson) writes: >We are presently experimenting with the TCP/IP protcol suite over an Ethernet >LAN. A useful guide to TCP/IP by Comer seems to suggest that TCP segment >size is user-definable. Is this true? Does anyone know how to define it? Since nobody else seems to have responded, I'll take a stab. Yes, in one sense. The TCP segment size is not a fixed value; rather, it is limited on the high side by a number of different considerations, and it should be no lower than necessary in order to get good performance. The upper limits on the size of a TCP segment are: (1) the TCP MSS option value; the receiving TCP specifies the largest segment it is willing to receive, and the sending host must abide. (2) the transmit side send buffer space limit. In BSD-based systems, this can be varied by the application program (within bounds). (3) the "Path MTU"; basically, the largest packet that can be sent from source to destination without fragmentation. (4) various considerations of the flow control and congestion control algorithms. Only #2 is under the control of the user, and in general the user would do well to leave it alone. The other limits are supposed to be set more or less automatically, in order to maximize performance. But, if you want to vary the segment size for experimental reasons, you'll probably have to modify the TCP code on both the sender and receiver; on the receiver, so that it sends a large enough MSS option, and on the sender, so that it choose the actual MSS you want it to use. (Existing TCPs often choose something like 1024 if the MSS option allows anything above that.)
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (09/21/90)
The upper limits on the size of a TCP segment are:
:
:
(3) the "Path MTU"; basically, the largest packet that can be sent
from source to destination without fragmentation.
In theory, there isn't any reason the tcp segment size cannot be larger
than the path MTU. (NFS essentially does this, though it doesn't use
TCP.) In practice, there are several reasons why doing this is a rather
bad idea - see Jeff's paper "Fragmentation Considered Harmful". Basically,
if you make the mss larger than the mtu, you force a lot of effort at the
routers (fragmentation), the destination (reassembly), and the network (if
it doesn't deliver all the fragments, the entire packet has to be retransitted)
BillW
-------DEDOUREK@UNB.CA (09/21/90)
On Fri, 21 Sep 90 04:17:00 CDT William Chops Westfield <BILLW@MATHOM.CISCO.COM> writes: > The upper limits on the size of a TCP segment are: > : > : > (3) the "Path MTU"; basically, the largest packet that can be sent > from source to destination without fragmentation. > To avoid fragmentation, can TCP MSS be equal to path MTU, or must it be less by some number of octets to allow for TCP and IP headers? If so, what is a good value? John D.
mwp@ubeaut.oz.au (Michael Paddon) (10/03/90)
From article <266@aldetec.oz.au>, by mawson@aldetec.oz.au (Graeme Mawson): > > We are presently experimenting with the TCP/IP protcol suite over an Ethernet > LAN. A useful guide to TCP/IP by Comer seems to suggest that TCP segment > size is user-definable. Is this true? Does anyone know how to define it? It surely is. On BSD based systems, the macro TCP_MSS is defined in /usr/include/netinet/tcp.h. This may be changed with impunity since the negotiation undergone at connection setup time chooses the smaller of the segment sizes supported by each implementation. There is not much point setting TCP_MSS to be greater than (maximum IP packet size - IP header size - TCP header size) [536 octets] since IP fragmentation will take place. Receipt of a fragmented packet is an all or nothing proposition; a good thing to avoid for throughput reasons. In general, the BSD TCP parameters in tcp.h and tcp_timers.h are close to optimal for ethernet (default RTT is a little pessimistic, but that is so the latter stages of backoff work properly). I found I had to do a fair bit of tuning to get everything right for a SLIP environment with flakey link hardware. Michael ------------------------------------------------------------------- | | Internet: paddon@meo78b.enet.dec.com | | | ACSnet: mwp@ubeaut.oz.au | | Michael Paddon | ACSnet: mwp@munnari.oz.au | | | EasyNet: meo78b::paddon | | | Voice: +61 3 895 9392 | -------------------------------------------------------------------
mogul@wrl.dec.com (Jeffrey Mogul) (10/05/90)
In article <ID9478.D900921.T090901.DEDOUREK@UNB.CA> DEDOUREK@UNB.CA writes: >To avoid fragmentation, can TCP MSS be equal to path MTU, or must >it be less by some number of octets to allow for TCP and IP headers? >If so, what is a good value? The Path MTU Discovery document (now an Internet Draft, soon to be an RFC if all goes well) says: Note: The TCP MSS is defined to be the relevant IP datagram size minus 40 [see RFC879]. The default of 576 octets for the maximum IP datagram size yields a default of 536 octets for the TCP MSS. In other words, the TCP MSS should be at least 40 octets less than the path MTU. -Jeff
postel@VENERA.ISI.EDU (10/05/90)
Hi. For further discussion of the TCP MSS see RFC 879. --jon. Date: 5 Oct 90 01:29:20 GMT From: bacchus.pa.dec.com!mogul@decwrl.dec.com (Jeffrey Mogul) Subject: Re: TCP segment size -- user defined? Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil In article <ID9478.D900921.T090901.DEDOUREK@UNB.CA> DEDOUREK@UNB.CA writes: >To avoid fragmentation, can TCP MSS be equal to path MTU, or must >it be less by some number of octets to allow for TCP and IP headers? >If so, what is a good value? The Path MTU Discovery document (now an Internet Draft, soon to be an RFC if all goes well) says: Note: The TCP MSS is defined to be the relevant IP datagram size minus 40 [see RFC879]. The default of 576 octets for the maximum IP datagram size yields a default of 536 octets for the TCP MSS. In other words, the TCP MSS should be at least 40 octets less than the path MTU. -Jeff
dc@gohp3.graphon.com (Darren Croke) (10/09/90)
In article <256@ubeaut.oz.au> mwp@ubeaut.oz.au (Michael Paddon) writes: > > text deleted > >There is not much point setting TCP_MSS to be greater than > (maximum IP packet size - IP header size - TCP header size) >[536 octets] since IP fragmentation will take place. Receipt of a >fragmented packet is an all or nothing proposition; a good thing to >avoid for throughput reasons. > The 536 octects in brackets is the minimum but by no means always equal to (maximum IP packet size - IP header size - TCP header size). Look at the packets on an Ethernet sometime. I am running a 4.3 BSD TCP/IP implementation here that quite happily negotiates a MSS of 1000 bytes and then proceeds to send unfragmented 1000 byte packets. I think you will find that it is common for IP implementations to send and accept datagrams without fragmentation up to (connected network MTU - IP header size - TCP header size). Darren Croke. dc@graphon.com
mwp@ubeaut.oz.au (Michael Paddon) (10/19/90)
From article <538@gohp3.graphon.com>, by dc@gohp3.graphon.com (Darren Croke): > In article <256@ubeaut.oz.au> mwp@ubeaut.oz.au (Michael Paddon) writes: >> >>There is not much point setting TCP_MSS to be greater than >> (maximum IP packet size - IP header size - TCP header size) >>[536 octets] since IP fragmentation will take place. Receipt of a >>fragmented packet is an all or nothing proposition; a good thing to >>avoid for throughput reasons. >> > I think you will find that it is common for IP implementations to > send and accept datagrams without fragmentation up to > (connected network MTU - IP header size - TCP header size). You are, of course, correct. The link-layer MTU is the important variable here, determining the maximum size of datagrams (up to 64K octets). I pulled the value 536 from some work I was doing with a SLIP implementation, forgetting at the time that it was a special case. Michael ------------------------------------------------------------------- | | Internet: paddon@meo78b.enet.dec.com | | | ACSnet: mwp@ubeaut.oz.au | | Michael Paddon | ACSnet: mwp@munnari.oz.au | | | EasyNet: meo78b::paddon | | | Voice: +61 3 895 9392 | -------------------------------------------------------------------