mouss wrote:
>
> I still can't see why a TCP packet need to be fragmented by the IP layer.
>
> Among hosts and routers that it crosses, the hosts (client and server) are
> normally the ones with lower MTU. But then, they talk TCP and can adjust
> their payload size. and before hat, first packets are small, so when is
> fragmentation of TCP packets happening?
Fragmentation occurs entirely at the IP layer and is transparent to the
TCP layer. TCP _receives_ a reassembled datagram from the IP layer with
no indication of whether or not fragmentation occured.
That having been said, TCP uses the minimum of the local interface MTU
and the MSS (maximum segment size) announced by the other end to
determine the amount of data it will _send_ in a single segment. (MSS
announcements are handled by a TCP option in SYN segments only. If it
is not there, a default MSS, typically 536, is assumed.) This only
avoids fragmentation due to the pathological case of exceeding MTU on
the directly connected networks of the end points. If an intermediate
network has an MTU that is lower than both the local MTU and the
announced MSS, fragmentation will still occur.
There is a way that TCP can avoid intermediate fragmentation. If Path
MTU discovery is supported, then the DF (don't fragment) bit will be set
in the IP header. Any intermediate device that must fragment the IP
datagram sends back an ICMP message to indicate the problem. TCP can
then adjust its segment size and resend.
As an example, an encrypted tunnel can cause fragmentation to occur if
PATH MTU discovery is not supported by the sender. As a result of
encapsulation or expansion of data size from some encryption a packet
may exceed some MTU in the tunnel path. In this case, the receiving end
reassembles the fragments at the IP layer into the original IP datagram
(invisible to TCP) while the sending end is none the wiser. Even if a
single fragment is lost, the sender is notified that the entire TCP
segment was lost just as if there had been no fragmentation.
See Stevens' TCPIPv1 pp. 148-157, 236-238, 340-344 for more detailed
info.
-paul
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
