Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!ames!ucbcad!ucbvax!SUVM.BITNET!JMWOBUS
From: JMWOBUS@SUVM.BITNET (John M. Wobus)
Newsgroups: comp.protocols.tcp-ip
Subject: Making TCP avoid fragmentation to help performance.
Message-ID: <8705272128.AA25799@ucbvax.Berkeley.EDU>
Date: Wed, 27-May-87 17:30:26 EDT
Article-I.D.: ucbvax.8705272128.AA25799
Posted: Wed May 27 17:30:26 1987
Date-Received: Sat, 30-May-87 04:20:48 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 21

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 University