[e2e] TCP in outer space

[Jon Crowcroft]

well, when i came in (1981) we were running TCP over connected ARPANET
, SATNET (.72 round trip time) and 10Mbps cambridge rins (the ethernet
didn't quite cut it yet then:-)

and we thought about the effect of RTT mean and variance getting bigger
(see phd by stephen edge back then from UCL - even talked about
fragmentation being a bad idea as i recall)

i am afraid that we _did_ do rocket science:-)
In message <20010413101839.B62628 at ted.isi.edu>, Ted Faber typed:

 >>
 >>--LyciRD1jyfeSSjG0
 >>Content-Type: text/plain; charset=us-ascii
 >>Content-Disposition: inline
 >>
 >>On Thu, Apr 12, 2001 at 09:17:53PM -0400, J. Noel Chiappa wrote:
 >>>     > From: Ted Faber <faber at ISI.EDU>
 >>> 
 >>>     >> since 1978, there has been no mystery that, for instance, TCP's
 >>>     >> retransmission algorithm has been given no means to distinguish among
 >>>     >> even the two most important causes of loss -- physical or queue drop.
 >>>  
 >>>     > Mechanisms based on internal network state were considered and
 >>>     > discarded because they conflicted with the well-defined and
 >>>     > well-prioritized list of design goals for the nascent Internet.
 >>>     > Specifically, depending on such internal information made the net less
 >>>     > robust to gateway failures .. so such mechanisms weren't included.
 >>>  
 >>> Actually, neither of these positions is right. The early Internet *did* try
 >>> and *explicitly* signal drops due to congestion, separately from drops due to
 >>> damage - that's what the ICMP "Source Quench" message was all about.
 >>
 >>I was thinking of more network specific ways to signal the event.
 >>You're right SQ was an attempt to do signal congestion in a
 >>transport-independent way.  I won't beat the horse about the
 >>differences between SQ and ECN.
 >>
 >>> In fact, the thing is that we just didn't understand a lot about the dynamics
 >>> of very large pure datagram networks, back in the late 70's when the initial
 >>> TCP work was being done. (And I'm not talking about only congestion, etc
 >>> here.) To start with, nobody had ever built one (the ARPAnet was *not* a pure
 >>> datagram network, for reasons I'm not going to explain here). With the *very*
 >>> limited amount of brain/programming power available in the early days of the
 >>> project (most of which was focussed on down-to-earth tasks like getting
 >>> packets in and out of interfaces), it's not too surprising that there were
 >>> lots of poorly-examined regions of the design space.
 >>
 >>My point was that the brain power seems to have made some a priori
 >>decisions about how to wade into the design space.  One of those was
 >>to favor robustness to efficiency.  That implies that once congestion
 >>systems were sufficient to keep the net running, that prioritization
 >>uregd brain power to be spent on robustness and swallowing new network
 >>technologies rather than tuning the congestion control for optimal
 >>efficiency.  It also suggests that when we get around to such
 >>tinkering, breaking the robustness of the net is a pitfall to beware.
 >>
 >>But I only know what I read in the papers; you were there, and if you
 >>tell me that I'm misunderstanding I'm probably misunderstanding.
 >>
 >>> 
 >>> But to get back to the topic, even ECN is at best a probabilistic mechanism
 >>> for letting the source know which drops are due to congestion, and which to
 >>> packet damage. The only "more reliable" (not that *any* low-level mechanism
 >>> in a pure datagram network is wholly reliable) method is SQ - and as I
 >>> mentioned, we just got through a long disquisition about how SQ is not the
 >>> right thing either.
 >>
 >>OK, I lied, I will mutter about the differences.  Unless you give ICMP
 >>packets preferential treatment with respect to drops, I think it's
 >>tough to characterize the relative reliability of the signals.  There
 >>are a lot of apples and oranges variables there - e.g., ECN's
 >>redundancy (multiple packets are likely to be marked) vs. SQ's shorter
 >>path through a (hopefully) less congested are of the net.  Even in the
 >>absence of other shortcomings, I don't think I'd believe an assertion
 >>about the relative reliabilities without a study or three.
 >>
 >>
 >>--LyciRD1jyfeSSjG0
 >>Content-Type: application/pgp-signature
 >>Content-Disposition: inline
 >>
 >>-----BEGIN PGP SIGNATURE-----
 >>Version: GnuPG v1.0.4 (FreeBSD)
 >>Comment: For info see http://www.gnupg.org
 >>
 >>iD8DBQE61zTvaUz3f+Zf+XsRAlg3AKDNOKrawJEwDHONitT4TW/udoV4oACfT3t4
 >>OolofDOxiIG0F48RcEBCgCw=
 >>=IXKg
 >>-----END PGP SIGNATURE-----
 >>
 >>--LyciRD1jyfeSSjG0--

 cheers

   jon