TCP MSS issue

HI,

I think you guys are not getting me, what I am asking.

I just want to know that,

1. Does all TCP segments are of equal size i.e. of MSS, until whatever
left in send buffer is less than the MSS?

2. Can we set the MSS size at application level, say using
setsockopt()?


Rajat

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

Rajat wrote:
> HI,
>
> I think you guys are not getting me, what I am asking.
>
> I just want to know that,
>
> 1. Does all TCP segments are of equal size i.e. of MSS, until whatever
> left in send buffer is less than the MSS?

No.

> 2. Can we set the MSS size at application level, say using
> setsockopt()?

Sort of. An application can /influence/ the MSS through appropriate syscalls.


- --
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

iD8DBQFBy8SYagVFX4UWr64RAsC2AJ9PgyVL83tLFU6TiYH3mE +3i320NwCfff1i
zYGSQo98u+OyvUcq2eHOX4M=
=zS0v
-----END PGP SIGNATURE-----

In comp.protocols.tcp-ip Rajat <(E-Mail Removed)> wrote:
> HI,

> I think you guys are not getting me, what I am asking.

I thing you are asking the wrong thing.

How TCP packtes data is done to make transmission more efficient,
that application has no need to know. The application receives
a stream of bytes - thats it !

If you need more detailed conrtrol over wire format use UDP or any
other encapsulation.


--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.

In article <cqgl1s$2t26$(E-Mail Removed)>, <(E-Mail Removed)> wrote:

:How TCP packtes data is done to make transmission more efficient,
:that application has no need to know. The application receives
:a stream of bytes - thats it !

Unless the application has done an I_SRDOPT ioctl to switch to
message-discard or message-nodiscard mode instead of byte stream mode.
--
What is "The Ultimate Meme"? Would it, like Monty Python's
"The World's Funniest Joke", lead to the deaths of everyone who
encountered it? Ideas *have* lead to the destruction of entire cultures.
-- A Child's Garden Of Memes

In article <(E-Mail Removed) >,
Rajat <(E-Mail Removed)> wrote:

:I think you guys are not getting me, what I am asking.

:I just want to know that,

:1. Does all TCP segments are of equal size i.e. of MSS, until whatever
:left in send buffer is less than the MSS?

I explicitly answered that question already, with quotations from
the appropriate man page. Repeating myself:

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.

"sends data when it is presented" means "sends the data when
the write() system call makes the data available to the TCP layer".
If you only write() a few hundred bytes, then that's the size of packet
that will be sent, if there are no outstanding ACKs or if you have
used setsockopt() to set TCP_NODELAY.

Refer back to my posting for further quotations from man pages
that talk explicitly about there being internal minimum and maximum
byte counts, and that if the write() size falls in between the limits
then the data will be sent immediately [except as modified by
the Nagle algorithm.] The usual cause, automatic fragmentation,
corresponds to the case of the lower limit being 0 that is discussed
in that man page section.


:2. Can we set the MSS size at application level, say using
:setsockopt()?

I answered that already too. Re-read the man pages I quoted
where it talks about pushing on a new top-level module. It is
in the same section that talks about the minimum and maximum byte
counts. Mentally invert the sens of what was written there:
where it says that the unless the application pushes a top-level
module that the application has no control over the limit values,
it is saying that if you *do* push a new top level module then
you have control over the limits.

Your previous posting didn't ask if you could "set" the MSS size,
it asked if you could *increase* the MSS. My response then discussed
why increasing the MSS is not usually a good idea.

If for some strange reason you needed to be able to change the MSS
size dynamically and you didn't want to go to the bother of
doing your own buffering and doing appropriately sized write()'s
that fell below the interface maximum MSS, then you could go the
streams module route and send a streams message to the appropriate
layer to change the MSS.
--
Can a statement be self-referential without knowing it?

Rajat wrote:
> HI,
>
> I think you guys are not getting me, what I am asking.

What we don't get is _why_ you are asking. We get _what_ you are
asking but you don't like the answers or have failed tyo understand
them.

> I just want to know that,
>
> 1. Does all TCP segments are of equal size i.e. of MSS, until
whatever
> left in send buffer is less than the MSS?

NO, NO, and NO How many times must we say this? (excuse my shouting)

TCP segment size (negotiated for a _particular_ connection) will
_generally_ remain the same _unless_ you use PMTU or a monitoring
mechanism in FW/routing that resets MSS to clamp it. There is NO --
get that, NO -- reason to increase it. It is adjusted downward on
tranfers to prevent packet fragmentation which can occur at _any_ point
_between_ the connecting hosts -- a condition they have _no_ control
over except to adjust packet size _downward_ to _avoid_ fragmentation.
These adjustments are available on most platforms via a means similar
to Linux's ipsysctl mechanism.

> 2. Can we set the MSS size at application level, say using
> setsockopt()?

_Apps_ would not want to set this from code as it would require root
priviledges and there is _already_ a means to set these values to
configure the system. Besides, the TCP/IP stack _already_ handles this
and _cannot_ be disabled. Stop trying to break your networking stack.
If you insist on doing this, then read the source, Luke.

Look here for a quick review of TCP connection/data tranfer:
http://www.tcpipguide.com/free/t_TCP...gementMech.htm

Check this RFC (among many others relevant to your questions):
http://www.faqs.org/rfcs/rfc1191.html
[quote]
3.1. TCP MSS Option
A host doing PMTU Discovery must obey the rule that it not send IP
datagrams larger than 576 octets unless it has permission from the
receiver. For TCP connections, this means that a host must not send
datagrams larger than 40 octets plus the Maximum Segment Size (MSS)
sent by its peer.
[end quote]
Note: in fact PMTU does not work as reliably as it could because of
brain dead net admins and broken implementations -- thus the
"workaround" noted above re: packet framentation and clamping MSS.

Perhaps -- just a wild guess here -- if you told us _why_ you are
interested in doing this, someone could provide more appropriate
suggestions of how to go about it.

I'm done with this -- plan to enjoy my Christams.
hth,
prg
email above disabled

Rajat wrote:
> HI,
>
> I think you guys are not getting me, what I am asking.
>
> I just want to know that,
>
> 1. Does all TCP segments are of equal size i.e. of MSS, until
whatever
> left in send buffer is less than the MSS?
>
> 2. Can we set the MSS size at application level, say using
> setsockopt()?

Excuse my self-followup -- left this out of last post:

http://www.faqs.org/rfcs/rfc879.html
RFC 879 - TCP maximum segment size and related topics
Cheers,
prg
email above disabled

In comp.os.linux.networking Rajat <(E-Mail Removed)> wrote:
> I think you guys are not getting me, what I am asking.

> I just want to know that,

> 1. Does all TCP segments are of equal size i.e. of MSS, until
> whatever left in send buffer is less than the MSS?

No. There may be several send()'s worth of data in the send buffer,
and the TCP may or may not slice and dice from those sends to produce
full-MSSed segments. You may often see long streams of MSS segments,
but you cannot ass-u-me it will always be that way.

Now, if it is a single send() it is _generally_ the case that all but
the last segment will be MSS - again though you cannot always ass-u-me
that - a short segment could in theory be generated by lack of remote
receive window, or perhaps even by the way the congestion window is
calculated.

So, you cannot always ass-u-me that a sort segment appearing after a
series of MSS segments means that was the end of a send().

> 2. Can we set the MSS size at application level, say using
> setsockopt()?

Depends on the stack. Some allow it, some do not.

rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...

"Rajat" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...

> I think you guys are not getting me, what I am asking.

Why do you care? You are probably on the wrong track entirely.

> 1. Does all TCP segments are of equal size i.e. of MSS, until whatever
> left in send buffer is less than the MSS?

If the number of bytes in the send buffer exceeds the MSS, there is no
reason for a TCP stack to send a packet that contains fewer bytes than the
MSS.

> 2. Can we set the MSS size at application level, say using
> setsockopt()?

Not usually. Typically the buffer sizes have no relation to the segment
sizes.

Again, why do you care? Unless your writing or debugging a TCP stack,
writing an invasive TCP packet proxy application, or writing a paper on TCP
internals, you should *definitely* not care. If you're working in
applications (which would be the only reason to ask about a socket option to
change the MSS), there should be absolutely no possible reason you should
care.

DS

In comp.protocols.tcp-ip Walter Roberson <(E-Mail Removed)> wrote:
> In article <cqgl1s$2t26$(E-Mail Removed)>, <(E-Mail Removed)> wrote:

> :How TCP packtes data is done to make transmission more efficient,
> :that application has no need to know. The application receives
> :a stream of bytes - thats it !

> Unless the application has done an I_SRDOPT ioctl to switch to
> message-discard or message-nodiscard mode instead of byte stream mode.

Never heard of it. Probable very portable :-)


--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.