[e2e] TCP fragmentation and reassembly

[Joe Touch]

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



Erwin Davis wrote:
> Hi, All,
> 
> Thanks for your info. RFC 879
> <http://www.networksorcery.com/enp/rfc/rfc879.txt> clearly explains the
> TCP fragmentation in the sending side but it
> says nothing about reassembly in the receiving side.

1. that's IP fragmentation, not TCP

2. that document was superceded by RFCs 791 (IP) and 793 (TCP).

> Joe, see an example below. Assume an application writes down a packet
> with 10 Kbyte to TCP layer whose negotiated MMS is 5 Kbytes.

Apps don't write packets; they write byte streams to TCP.

> Then the
> TCP layer will fragment the application packet into two TCP segments
> with 5 Kbytes each. Assume that the first TCP packet arrives at the
> receiving side. Then the TCP layer in the receiving side wakes up the
> application listening to this TCP port. The application processes the
> half packet and fails.

The application has no business assuming this is a packet. It's a byte
stream. If it needs packet boundaries, it should keep reading until it
sees the packet boundary (which the app on the sending side must
insert). This is how HTTP works.

> The app has no way to know if it receive a
> complete message or not but the TCP layer in the sending side knows.

The app has to insert framing - either an 'end of packet' reserved byte
or to use its own headers. Again, this is how HTTP works.

> To
> me,  such TCP operation is not transparent to the application. It
> requires the intelligent part in the application to determine if the
> arriving TCP packet is a complete packet from the sending application or
> not.
> let me know if I misunderstood some points.  Thanks again,
> 
> Erwin
> 
> On 12/5/05, *Joe Touch* <touch at isi.edu <mailto:touch at isi.edu>> wrote:
> 
> Erwin,
> 
> It's useful to keep in mind that TCP is a byte-stream protocol; there
> are no segment boundaries preserved between application and
> transport layer:
> 
> Erwin Davis wrote:
>> Helllo,
> 
>> Packet from application layer may be framed in TCP layer based on MSS
>> (maximum segment size, not MTU in IP layer) negotiated between two TCP
>> layers of the end parties.
> 
> Apps using TCP don't write in packets; they write bytes. The application
> can write in whatever units it wants; TCP is allowed to send packets
> based on that data however it sees fit. While an application can
> tune to
> the behavior of a specific TCP implementation, it cannot rely on all
> TCPs acting the same way.
> 
>> My question is if the TCP layer in receiving
>> side will reassemble the TCP fragments before it forward the
> packet to
>> the application layer.
> 
> TCP reorders, but doesn't maintain application layer boundaries. So long
> as data is received in order, once it is received and ACK'd it is
> presented to the receive-side application layer.
> 
>> If yes, then how the TCP layer in receiving side
>> knows how many TCP fragments are made up for this one application
>> packet. If not, will it require the intelligence from the application
>> layer for the application packet reassembly. Thanks for your help,
> 
> Applications cannot strictly know what TCP does with data that is sent
> absent monitoring the traffic directly.
> 
> Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDlOdwE5f5cImnZrsRAvtlAJ42tyQy7mdzMLqyPeos11SEnzGu/gCghiGz
XDpkiQLeC7G8IjJBPzxfnbE=
=1IX+
-----END PGP SIGNATURE-----