JMWOBUS@SUVM.BITNET (John M. Wobus) (05/28/87)
Here are two principles:
(1) The two directions of the TCP connection should be handled independently,
because fragmentation may be different in the two directions.
(2) Though the degree of fragmentation may change over time, we can assume
that recent history is a pretty good predictor of the near future.
I suggest that the "receiving TCP" be given an indication that a packet
was fragmented and that it indicate this fact in its acknowledgement.
When the "sending TCP" gets the acknowledgement, it can try sending in a
smaller size packet. Then, once in a while, the "sending TCP" might try
increasing the packet size to "test the waters".
This is something like the way TCP handles RTTs when deciding when it is time
to resend. These two problems seem similar to me. I presume the most
radical part of this proposal is to add a 1-bit field to the TCP header,
something one wouldn't want to do every day.
John Wobus
Syracuse Universitytappan@MIKEY.BBN.COM (05/29/87)
>>Date: Wed, 27 May 1987 17:03:40 LCL >>From: John M. Wobus <JMWOBUS%SUVM.BITNET@wiscvm.wisc.edu> >>To: TCP-IP Discussion Group <TCP-IP@SRI-NIC.ARPA> >>Subject: Making TCP avoid fragmentation to help performance. >> (omitted) >> ...... I presume the most >>radical part of this proposal is to add a 1-bit field to the TCP header, >>something one wouldn't want to do every day. If we're talking about changing the protocols maybe what we need is something like this: The sort of fragmentation and congestion problems that exist are caused by one thing - lack of information on the part of the sender as to what's happening to the data it has sent out. For IP messages if a message gets fragmented and a piece gets lost the sender never knows it, and has no choice but to eventually retransmit the whole thing (which may get fragmented in the same way). The same problem exists for the transport level protocols. If a TCP sends several consecutive segments and one in the middle is lost then it gets no feedback on any of them. All it can do is wait out the retransmission timeout and resend some or all of the unacknowledged data. Consider an ICMP message like the following: ---------------- Fragment Missing 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + 64 bits of Original Data Datagram | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type ??? Code 0 = IP fragments missing 1 = Transport Protocol fragment missing If Code = 0 then the message refers to a IP datagram that was fragmented. The sender has received some of the fragments but is missing others. The IP header contained in the message indicates the "fragment offset" of missing fragment(s). The "total length" indicates how much of the datagram is missing at that point. If Code = 1 then the message indicates that the some the Transport Protocol is has lost data. The included header indicates which data is missing, for example for TCP the TCP "sequence number" and IP "total length" fields would define the missing data. --------------- How this might be used: 1) If a host receives several fragments of a message and one in the middle is missing there is a good chance (given the way the Internet actually works) that that fragment is lost. Instead of waiting for the reassembly timeout the host can send back a Code 0 "fragment missing" message. With luck and proper implimentation the other host can recreate the missing fragment and send out only it. Even if it can't recreate the fragment it can use the message as a strong hint as to how large messages can get before fragmentation becomes a problem. After all, the issue isn't really how large messages can get without being fragmented - if all the fragments are delivered then throughput is probably better then if the message has been sent in smaller segments - the problem is when messages both get fragmented AND the fragments are sent over an unreliable channel. 2) If the last fragment of a message is missing it takes the receiving host longer to realize it, but it could send out a Code 0 message instead of (or sooner then) a "Reassembly time exceeded" message. If several fragments of the message arrive it can get a good idea whether the last fragment is missing by watching the arrival times. 3) If a transport level protocol receives out of sequence data it can also assume that a segment is missing and produce a Code 1 message which wll tell the sender to retransmit only that much data. Note that in any of these cases if the ICMP message is not delivered all that happens is that we revert to the current situation.