Reed's views, was [e2e] Cannara's views

Cannara cannara at
Wed Apr 25 09:43:04 PDT 2001


I got away with a x10 error in Beethoven's download time!  And, I believe I
quoted your words, trying to understand their meaning, not putting any in your

The byte-counting issue has not to do with 36-bit DEC 10s vs 32-bit PDP-11s,
DG Novas, etc., but with the odd assignment of importance to counting
character equivalents in a packet protocol.  A huge sequence counter is
included and accepted in TCP, while an arm's-length list of other transports
simply have had packet counters, while still achieving reliability, backoff,
etc.  So, bits that could have been used for other purposes, or saved, are
repeatedly stuffed into TCP packets.  All this while the network-address makes
do with less than half the number of bits it could have.  And, we're not
talking about running TCP/IP under the typical industry development cycle
here, we're talking a couple of decades of available, subsidized time, largely
in parallel with other, deployed, protocol existence proofs.


"David P. Reed" wrote:
> At 10:54 PM 4/14/01 -0700, Cannara wrote:
> >...Au contraire, TCP/IP was optimized for small MTU, 56kb/s, byte-oriented
> >transfers, implemented on 16-bit machines that could do 32-bit (double-word)
> >ops.  In other words, Telnet, RPC, FTP, etc.  TCP still counts bytes in
> >sequence #s.  When all 3GBytes of Beethoven's symphonies can be ATMed in
> >19sec, or OC48'd in 1 second, having a transport getting fooled by false
> >congestion positives and dropping out for a second or so doesn't really make
> >sense, no matter how many times we click our slippers and say: "I didn't
> >optimize", "I didn't optimize"...
> Huh?  To the extent this even makes some sense to parse, it is wrong.  The
> dominant early machines were PDP-10's - 36-bit machines - and there was a
> huge debate about "endian-ness" that pointed out the need for clear
> definitions in the protocols.  TCP counts bytes in sequence numbers, but
> there was a debate about going to 64-bits because we were worried that RTT
> might exceed the 8 gigabyte wraparound we had planned for.  So what?  Would
> counting ATM cells have been a few percent more efficient?
> >..."Wholly false" -- so all new technology was anticipated, but ignored
> >  Why,
> >because clairvoyance was assigned no value?  What do you know of the future
> >now that you're not telling us and that networking can safely ignore?  I can't
> >imagine this is what you mean by "wholly false".
> You're right. That's not what I meant.  So why are you putting words in my
> mouth?

More information about the end2end-interest mailing list