Re: determining RTTs

5 Nov 1986 10:23-EST

        I was experimenting with those ideas a couple years ago;
the results were encouraging. I tried to use a "new" tcp option
but discovered that one "legal" interpretation of the tcp spec
lead to an implementation which rejected any tcp connection which
contained an option which wasn't listed in the spec (don't know
if it has a one-byte or multiple-byte format therefore cannot
parse it).

        To minimize the impact with existing implementations I
passed information in the usually unused urgent pointer field
(the option was to inform the remote system that the field was
being used in this manner). The information was thus carried
at no extra cost through the net. The 16 bits were divided into
three fields: 3 for the retransmission number of the packet/data,
zero to six, or more (sender to receiver information); 3 for the
retransmission number of the packet which contained the oldest
data byte necessary to advance the ack (receiver to sender
information); and 10 for the size of any gap at the receiver.
The 3 bit fields seemed to be sufficient except in cases where
the destination had actually become unreachable. There could be
some ambiguity if acks were lost, but that was minimized by only
retransmitting one packet's worth of data. The size of the gap
was useful to limit retransmission of packets that had been
received after one which had been dropped, especially for those
systems which ack every packet received instead of just the last
in their receive queue.

PS: The code to fill in the urgent field as described above was in
the last BBN release of network code for TOPS20; feel free to
carry on the experimentation.

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:59 GMT