[ih] TCP RTT Estimator

[John Day]

I would go further and say that this is a general property of layers. We tend to focus on the service provided by a layer, but the minimal service the layer expects from supporting layers is just as important.

The original concept of best-effort and end-to-end transport (circa 1972) was that errors in the network layer were from congestion and rare memory errors during relaying. Congestion research was already underway and the results were expected to keep the frequency of lost packets fairly low. Thus keeping retransmissions at the transport layer relatively low and allowing the transport layer to be reasonably efficient.

For those early networks, the link layer was something HDLC-like and so reliable. However, it was recognized that this did not imply that the Link layers had to be reliable, but have an error rate well below the error rate created by the network layer. Given that there would be n link layers contributing to the additional error rate, where n is the diameter of the network, it is possible to estimate an upper bound that each link layer must meet to keep the error rate at the network layer low enough for the transport layer to be effective.

There were soon examples of link layers that were datagram services but sufficiently reliable to meet those conditions, e.g., Ethernet. Later, to take up the packet radio topic, 802.11 is another good example, where what happens during the NAV (RTS, CTS, send data, get an Ack) is considered ‘atomic’ and if the Ack is not received, it is assumed that the packet was not delivered. (As WiFi data rates of increased this has been modified.) This seems to have the same property of providing a sufficiently low error rate to the network layer that transport remains effective. (Although I have to admit I have never come across typical goodput measurements for 802.11. They must exist, I just haven’t encountered them.)  ;-)

One fun thing to do with students and WiFi is to point out that the original use of the NAV makes WiFi a stop-and-wait protocol. Most textbooks use stop-and-wait as a simple introductory protocol and show that under most circumstances would be quite slow and inefficient. Then since they use WiFi everyday is it slow? No. Then why not? ;-)

It leads to a nice principle of protocol design.

Take care,
John

> On Mar 24, 2025, at 20:16, Greg Skinner via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> 
> On Mar 11, 2025, at 2:48 PM, Barbara Denny <b_a_denny at yahoo.com> wrote:
>> 
>> I don't recall ever hearing, or reading, about TCP transport requirements from the underlying network but I wasn't there in the early days of TCP (70s).?
>> I have trouble thinking the problem with the congestion assumption? wasn't brought up early but I certainly don't know.
>> barbara
>>   On Tuesday, March 11, 2025 at 02:10:26 PM PDT, John Day <jeanjour at comcast.net> wrote:  
>> 
>> I would disagree. The Transport Layer assumes a minimal service from the layers below (actually all layers do). If the underlying layer doesn?t meet that normally, then measures are needed to bring the service up to the expected level.? Given that the diameter of the net now is about 20 or so and probably back then 5 or 6. Packet radio constituted a small fraction of the lower layers that the packet had to cross. Assuming packet radio didn?t have to do anything had the tail wagging the dog.
>> 
>> Of course the example some would point to was TCP congestion control assuming lost packets were due to congestion. That was a dumb assumption and didn?t take a systems view of the problem. (Of course, it wasn?t the only dumb thing in that design, it also maximized retransmissions.)
>> 
>> Take care,
>> John Day
>> 
>>> On Mar 11, 2025, at 17:02, Barbara Denny via Internet-history <internet-history at elists.isoc.org> wrote:
>>> 
>>> I do view packet radio as a stress test for the protocol(s).? I think it is important to consider all the different dynamics that might come into play with the networks. 
>>> I still need to really read Jack's message but there were also military testbeds that had packet radio networks.? I don't know what these users were trying to do. I was only involved if they experienced problems involving the network. My role was? to figure out why and then get it fixed (with whatever contractor that was working that part of the system, including BBN).
>>> barbara 
>>> 
> 
> For what it's worth, there was a discussion on this list back in 2016 about early TCP work and how packet radio networks were involved. [1] [2] Based on what I’ve been able to find, I would agree with John that most Internet traffic didn’t cross packet radio networks back then.  The Ft. Bragg testbed was one of the most used, as far as I can tell.
> 
> As for people who tried to deal with how inherent loss problems of packet radio networks affected TCP, I did find a comp.protocols.tcp-ip thread from 1987 on that subject.  [3] Jil Westcott, who contributed to the thread, also had email correspondence with Zaw-Sing Su in the Ft. Bragg PRNET simulation paper he wrote.
> 
> --gregbo
> 
> [1] https://elists.isoc.org/pipermail/internet-history/2016-August/thread.html
> [2] https://elists.isoc.org/pipermail/internet-history/2016-September/thread.html
> [3] https://groups.google.com/g/comp.protocols.tcp-ip/c/vuPqc12SLis/m/1GoOsEem954J
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history