TCP packet size

[Oumer Teyeb]

In many TCP simulators (such as ns-2), it is assumed that once the
connection is established, TCP packets are of some fixed size. But is this
true in real connections? And if not what makes it vary? My understanding
is, for example if I am using http services, I am sending some small
commands to get pages, and this may not fit the whole MSS, so the packet
will be less than MTU after header additions. That is the only reason I can
think of for TCP/IP packet sizes to be less than the MTU. Is there any other
reason?

[Alexander Kotelnikov]

>>>>> On Wed, 21 May 2003 21:50:29 +0200
>>>>> "OT" == Oumer Teyeb <ou...@kom.auc.dk> wrote:
OT>
OT> In many TCP simulators (such as ns-2), it is assumed that once the
OT> connection is established, TCP packets are of some fixed size.

Sounds very strange.

OT> will be less than MTU after header additions. That is the only reason I can
OT> think of for TCP/IP packet sizes to be less than the MTU. Is there any other
OT> reason?

Read famous Kent & Mogul article "Fragmentation Considered Harmful".

--
Alexander Kotelnikov
Saint-Petersburg, Russia

[oumer]

I think you misunderstood my question. I am talking about TCP packet
sizes, not IP packet sizes. Sure there will be fragmentation when
entering a link that doesn't support the packet size, but at the sender
side, if there is a constant supply of data (ex. FTP service), then is
there a possibility that the size of the TCP packets that are given to
the IP layer can vary in size??

[Wartan Hachaturow]

oumer wrote:

> side, if there is a constant supply of data (ex. FTP service), then is
> there a possibility that the size of the TCP packets that are given to
> the IP layer can vary in size??

Sure. For example, if one side of the connection declares a window size
of zero or just advertises the smaller window, then the size of packets
sent by the other side decreases -- the other side my even stop sending
data packets at all (other than window probes).

The whole thing is called "congestion control", and described in
RFC2581, for example. Size of TCP packets sent to IP layer always
get changed to reflect current network and talking host's status.

--
Regards, Wartan.
"Computers are not intelligent. They only think they are."

[oumer]

the advertised window (awnd), as far as I understand is how much bytes
are available at the receiver's receive buffer. So lets set an example
(the numbers may not be practical, but ...)

everything was going ok at start, Sender is sending 500 byte packets,
the awnd was set to 2000bytes at the receiver. So the receiver will be
able to send z=min(cwnd, awnd) = 2000 bytes without receiving an ack for
them (outstanding data) and let's say the cwnd is higher than the awnd
at the instant we are considering, so the limiting factor is awnd only.
So the sender can inject 4 packets into the network.
Now something happend in the receiver (high priority interrupt or
something else) and the receiver's TCP didn't have enough time to pass
all the data from its receive buffer to higher layers, and it advertises
an awnd of 750 bytes.

Now there are several possibilites of taking care of this situation when
the sender gets this awnd value

a. Since 750 bytes make it able to send one 500 byte packet, I will send
one packet.
b. Change the packet size to 750 bytes, so that it could use the whole awnd
c. lower the packet size to 250 bytes so that it could send three whole
packets ....

and there are many other possibilities.....

So which option is taken? If packet size doesn't change due to awnd
(which I think is right), then only option (a) above will be useful. but
it seems that it will slow the TCP throughput. IF packet size changes
,then the sender have lots of possibilites and which one does it take?

I can understand the need to change the packet size when you have
intermittent connection like http, but when you have a constant flow of
data going on, it seems to be very difficult to find out the mechanism
to calculate the packet sizes to use since there are lots of possibilites.

I hope you get my problem .....

[Fernando Gont]

On Thu, 22 May 2003 11:59:14 +0200, oumer <ou...@cpk.auc.dk> wrote:

>Now something happend in the receiver (high priority interrupt or
>something else) and the receiver's TCP didn't have enough time to pass
>all the data from its receive buffer to higher layers, and it advertises
>an awnd of 750 bytes.

It will usually be simpler: the peer app hasn't read() the data.

>Now there are several possibilites of taking care of this situation when
>the sender gets this awnd value
>a. Since 750 bytes make it able to send one 500 byte packet, I will send
>one packet.
>b. Change the packet size to 750 bytes, so that it could use the whole awnd

If the sending TCP was sending 500-byte segments, why should it try to
send a 750-byte segment in this case????

>c. lower the packet size to 250 bytes so that it could send three whole
>packets ....
>and there are many other possibilities.....

No. Whenever it's possible, send a MSS-sized segment (i.e., a 500-byte
segment, in this case). If it's not possible, then send a 250-byte
segment. (*)

>So which option is taken? If packet size doesn't change due to awnd
>(which I think is right), then only option (a) above will be useful. but
>it seems that it will slow the TCP throughput.

Why do you think this?

>I can understand the need to change the packet size when you have
>intermittent connection like http, but when you have a constant flow of
>data going on, it seems to be very difficult to find out the mechanism
>to calculate the packet sizes to use since there are lots of possibilites.
>I hope you get my problem .....

As I said above, whenever it's possible, TCP will send MSS-sized
segments (*). If there are no enough data in the socket send buffer,
it will send as many bytes as possible.

(*) Actually, if the MSS announced by the other end is higher than the
outgoing MTU minus the size of the IP and TCP headers, the sending TCP
will send segments smaller than MSS bytes.

--
Fernando Gont
e-mail: fern...@ANTISPAM.gont.com.ar

[To send a personal reply, please remove the ANTISPAM tag]

[Fernando Gont]

On Thu, 22 May 2003 09:30:55 +0200, oumer <ou...@cpk.auc.dk> wrote:

>I think you misunderstood my question. I am talking about TCP packet
>sizes, not IP packet sizes. Sure there will be fragmentation when
>entering a link that doesn't support the packet size, but at the sender
>side, if there is a constant supply of data (ex. FTP service), then is
>there a possibility that the size of the TCP packets that are given to
>the IP layer can vary in size??

If at any time your TCP has fewer data to send than that for a
MSS-sized segment, then you may see TCP segments which will vary in
size.

[Jens Nelke]

Hi,

it sounds like you are mixing up window size and packet size. As I remember
the windowsize controls the number of packets which may be processed and
send without any feedback from the peer. The size of the packet is not
influenced. If you set the windowsize to 0 the TCP stack will send one
packet and afterwards wait for a response until he sends the next one.
Please correct me if I'm wrong.

Jens Nelke

-------------------------------------------------------------------------
Dipl.-Ing. Jens Nelke Datentechnik Intercom GmbH
Entwicklung Frankenring 14
30855 Langenhagen
-------------------------------------------------------------------------
Tel.: +49 511 978197-657 <http://www.keymile.com/>
Fax.: +49 511 978197-670 <mailto:jens....@keymile.com>
-------------------------------------------------------------------------