Dear All,

I have some doubts regarding TCP's MSS option.

1. Is it true that TCP breaks all the byte stream to be send, into
fixed size data segments each of size of MSS, not less until the data
left in send buffer is less than MSS size. Or the length of segment
can vary(having the MSS size as upper limit) and not in our control.

2. I read some where that we can't increase the value of MSS option,
we can only decrease it. Is it true?

[ Post a follow-up to this message ]

On 2004-12-23, Rajat <myself_rajat@yahoo.com> wrote:
> Dear All,
>
> I have some doubts regarding TCP's MSS option.
>
> 1. Is it true that TCP breaks all the byte stream to be send, into
> fixed size data segments each of size of MSS, not less until the data
> left in send buffer is less than MSS size. Or the length of segment
> can vary(having the MSS size as upper limit) and not in our control.

Yes and no. All the data is sent, nothing is left in the buffer. But the
data is send in segments. There're some additional things like Nagle
algorithm involved, but those *in general* don't make any difference.
>
> 2. I read some where that we can't increase the value of MSS option,
> we can only decrease it. Is it true?

Why would it be so important for you? TCP is created to hide all these
details from you. I understand that there could be situations, when the
data must be sent within single segment and shouldn't be broken. Then
this data has the danger of being rejected by some networks that can't
pass segments of such size. But in general, TCP handles stream of data
which can be broken in parts and then again reassembled on the receiving
side. So, the only thing needed is support for this reassembly in
receiver. And this is easy, since all parts arrive in exactly the same
order. The program just needs to append each new part to the end of
the previous one.

Andrei

[ Post a follow-up to this message ]

In article <b49ef75a.0412222226.30a11ffd@posting.google.com>,
Rajat <myself_rajat@yahoo.com> wrote:
:I have some doubts regarding TCP's MSS option.

:1. Is it true that TCP breaks all the byte stream to be send, into
:fixed size data segments each of size of MSS, not less until the data
:left in send buffer is less than MSS size. Or the length of segment
:can vary(having the MSS size as upper limit) and not in our control.

Quoting from the IRIX 'tcp' man page:

TCP_NODELAY
Under most circumstances, TCP sends data when it is presented; when
outstanding data has not yet been acknowledged, it gathers small
amounts of output to be sent in a single packet once an
acknowledgement is received.  For a small number of clients, such as
window systems that send a stream of mouse events which receive no
replies, this packetization may cause significant delays.
Therefore, TCP provides a boolean option, TCP_NODELAY, to defeat
this algorithm.


The Nagle algorithm is in RFC 896.

See also the write(2) man page. On IRIX, it includes this:

For STREAMS files [see intro(2)], the operation of write is determined b
y
the values of the minimum and maximum nbyte range (``packet size'')
accepted by the stream.  These values are contained in the topmost stream
module.  Unless the user pushes the topmost module [see I_PUSH in
streamio(7)], these values can not be set or tested from user level.  If
nbyte falls within the packet size range, nbyte bytes are written.  If
nbyte does not fall within the range and the minimum packet size value is
zero, write breaks the buffer into maximum packet size segments prior to
sending the data downstream (the last segment may be smaller than the
maximum packet size).  If nbyte does not fall within the range and the
minimum value is non-zero, write fails and sets errno to ERANGE.


It should also be understood that the number of bytes that is sent in
a packet is not necessarily the number of bytes that the far end will
read. Here's an excerpt from the IRIX read(2) man page:

A read or readv from a STREAMS [see intro(2)] file can operate in three
different modes: byte-stream mode, message-nondiscard mode, and message-
discard mode.  The default is byte-stream mode.  This can be changed
using the I_SRDOPT ioctl(2) request [see streamio(7)], and can be tested
with the I_GRDOPT ioctl(2) request.  In byte-stream mode, read and readv
usually retrieve data from the stream until they have retrieved nbyte
bytes, or until there
is no more data to be retrieved.  Byte-stream mode usually ignores
message boundaries.

In STREAMS message-nondiscard mode, read and readv retrieve data until
they have read nbyte bytes, or until they reach a message boundary.  If
read or readv does not retrieve all the data in a message, the remaining
data is replaced on the stream and can be retrieved by the next read or
readv call.  Message-discard mode also retrieves data until it has
retrieved nbyte bytes, or it reaches a message boundary.  However, unread
data remaining in a message after the read or readv returns is discarded,
and is not available for a subsequent read, readv, or getmsg [see
getmsg(2)].



:2. I read some where that we can't increase the value of MSS option,
:we can only decrease it. Is it true?

See above: you can push a new top-level module that has a larger
MSS. However, if you increase your MSS such that
(MSS plus the TCP overhead plus IP overhead plus link layer overhead)
plus (any VPN overhead plus any GRE or PPP encapsulation overhead)
is bigger than the maximum allowed by your Layer 2, the resulting
packet will be counted as an error and discarded. Increasing the MSS
is thus usually of little practical value.


You -can- usefully increase the MSS in a couple of circumstances:

- you set it lower for some reason, and you want to restore it to
not more than its previous maximum

- you set your MSS based upon worst-case IPSec or PPPoE overhead, but
through testing determine that you are not hitting the worst case, so you
want to increase to what the link will actually bear without
fragmentation

- you enable "jumbo frames" where all equipment along the line has
support for jumbo frames

- your network connection starts to take a different path part way
through a conversation, and the new path has a higher limit

- your primary link fails (or returns to operation) part way through
a conversation, and the new (or restored) link is through a different
media with a larger limit


Different media types have different MSS. The table that is in
IRIX's 'bsd' kernel configuration module indicates,

int tcp_mtutable[] = {
65535,
65280,  /* HIPPI */
32768,
17914,
9180,   /* ATM */
8166,   /* 802.4 */
4352,   /* FDDI */
2002,
1492,   /* Ethernet/802.3 */
1006,   /* Arpanet */
508,
0 /* ZERO MUST TERMINATE THIS LIST! */ };

IRIX also happens to allow configuration of the maximum MTU on a
per-interface basis for Tigon 3 gigabit cards. It's 'if_eg' kernel
configuration module has a table of 32 MTUs, with the default
values all set to 1500 if jumbo frames are not enabled in the kernel,
and all set to 9000 if they are enabled. If one had a good reason to,
one could change those values and generate a new kernel.
--
Ceci, ce n'est pas une idée.

[ Post a follow-up to this message ]

Rajat wrote:
> Dear All,
>
> I have some doubts regarding TCP's MSS option.

Doubts or confusion?

> 1. Is it true that TCP breaks all the byte stream to be send, into
> fixed size data segments each of size of MSS, not less until the data
> left in send buffer is less than MSS size. Or the length of segment
> can vary(having the MSS size as upper limit) and not in our control.

You can write() as much as you want from your app.  You cannot control
the TCP segmentation from your app -- wouldn't make sense to try since
there is no way to know what environment it will be used in or net
conditions between end points at the time of use.  See this eg.:

http://www.uwsg.iu.edu/hypermail/li...002.1/0079.html

> 2. I read some where that we can't increase the value of MSS option,
> we can only decrease it. Is it true?

There are _some_few_ settings you can play with in Linux TCP
configuration re: MSS but in real use MTU and WindowSize settings and
snd/rcv buffers will dominate just about anything you can change with
MSS.  Noramlly, MSS _changes_ are meant to _clamp_ MSS to prevent
packet fragmentation (and thus _increase_ network throughput). See:

- http://lartc.org/howto/lartc.cookbook.mtu-mss.html
- http://linux-ip.net/html/routing-ic...outing-icmp-mtu
- your ip-cref docs on your disk
- http://www.linuxforum.com/man/tcp.7.php or 'man tcp'
- http://www.google.com/search?q=linu...=UTF-8&oe=UTF-8

It is not clear if you are thinking of app programming code or TCP
settings available via /proc/sys/net/ipv4 -- I am assuming the latter.
hth,
prg
email above disabled

[ Post a follow-up to this message ]

"Rajat" <myself_rajat@yahoo.com> wrote in message
news:b49ef75a.0412222226.30a11ffd@posting.google.com...

> I have some doubts regarding TCP's MSS option.

> 1. Is it true that TCP breaks all the byte stream to be send, into
> fixed size data segments each of size of MSS, not less until the data
> left in send buffer is less than MSS size. Or the length of segment
> can vary(having the MSS size as upper limit) and not in our control.

> 2. I read some where that we can't increase the value of MSS option,
> we can only decrease it. Is it true?

Why do you care about the internal details of TCP at this level? These
types of questions are usually asked by people who are looking in the wrong
places. Applications don't have to know about TCP internals, and when they
think they do, they're probably getting into trouble.

(You can ignore this if you're dealing with things like routers, proxies
at the packet level, or TCP/IP stack software.)

DS

[ Post a follow-up to this message ]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rajat wrote:
> Dear All,
>
> I have some doubts regarding TCP's MSS option.
>
> 1. Is it true that TCP breaks all the byte stream to be send, into
> fixed size data segments each of size of MSS, not less until the data
> left in send buffer is less than MSS size.

No, it is not true.

While TCP normally breaks it's byte-stream data into segments of a
predetermined size, there are occassions (outside of the short segment at th
e
end of the stream) where TCP will send a smaller segment than normal.
Typically, these short segments are sent in conjunction with a scheduling
algorithm known as the "Nagle Algorithm", but short segments can be generate
d
as a result of other conditions as well.

> Or the length of segment
> can vary(having the MSS size as upper limit) and not in our control.

This is a true, but incomplete, statement.

> 2. I read some where that we can't increase the value of MSS option,
> we can only decrease it. Is it true?

MSS is 'agreed apon' between the two partner stacks in a TCP conversation.
Once the conversation is started, I don't believe that there is a programmat
ic
way of increasing the value used between the partners. However, IIRC, there
are ways of programmatically increasing the local stack's MSS value prior to
the initiation of a conversation. I believe that this takes specific ioctl()
calls on an open raw socket to execute, and only affects one side of the
conversation. If the other side has a smaller MSS, then it shouldn't matter
how much you increase this side's MSS; the smaller MSS 'wins' the agreement.

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

 iD8DBQFBy7sbagVFX4UWr64RAuJSAJ9fSchRS4Qj
hMNun6jPt54SnY1R8gCgnEhC
Oe/tVUulhRyuUJ0QTCuxakU=
=PkTL
-----END PGP SIGNATURE-----

[ Post a follow-up to this message ]