[ih] Loss as a congestion signal [internet-history Digest, Vol 84, Issue 4]

[Louis Mamakos]

On May 21, 2014, at 4:02 PM, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:

> On 22/05/2014 07:08, Noel Chiappa wrote:
> 
>> I fairly vividly remember being the IETF where Van gave his first talk about
>> his congestion work, and when he started talking about how a lost packet was
>> a congestion signal, I think we all went 'wow, that's so obvious - how come
>> we never thought of that'!
> 
> I wasn't there so I have no right to comment on this, but it's
> surely the case that actual bit destruction causing non-congestive
> packet loss was a much bigger worry in the 1970s than it was
> ten years later?
> 
> And indeed when actual packet loss became a significant factor
> with the rise of wireless networks some years ago, it proved
> that treating it mainly as a congestion signal was (and is)
> problematic. If you have a path that includes both loss-prone
> and congestion-prone segments, TCP doesn't work so well.
> (See http://www.ietf.org/proceedings/87/slides/slides-87-nwcrg-4.pdf
> for example.)
> 
>   Brian

I think there was some awareness of this at the time.  When the NSFNET 
phase-1 deployment planning begin, some of us at U of MD were involved in
the procurement of the LSI-11 fuzzball systems.  Of course, Dave Mills
was deeply sucked into this at the time, and I vaguely remember a conversation
with him regarding the use of DMV-11 Q-bus synchronous serial interfaces.

These devices did some sort of ARQ between themselves, and being then
still wet-behind-the-ears, I asked Dave why we didn’t just rely on 
IP and TCP checksums for reliable transport?  I think based on his 
experience over very lossy packet radio paths, it was revealed that
eliminating hop-by-hop loss due to damage would be value to avoid 
provoking TCP’s retransmit mechanism.  And with only 56kb/s trunks
between the fuzzballs in the NSFNET phase 1 network, there was ample
opportunity to explore the congestion domain..

I also remember being there in Cambridge for Van’s early presentation
on TCP congestion and the application of control theory.  At the time
I thought I was fortunate because the IP/TCP implementation for our
UNIVAC 1108 system was “working”, and then it became clear there was
much more work to be done!  I don’t think that people realize how much
they take for granted the interoperability in protocol implementation
we generally enjoy today.  Certainly we all learned quite a bit with
the early implementations; heck, who even worries about sequence space
wrapping around and getting the math to work right on your 36-bit
one’s-complement CPU. 

louie