Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!yale!husc6!caip!lll-crg!nike!ucbcad!ucbvax!BRUBECK.PROTEON.COM!jas
From: jas@BRUBECK.PROTEON.COM
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Re: RING vs. ETHER - Theory and practice.
Message-ID: <8607211509.AA12215@ucbvax.Berkeley.EDU>
Date: Mon, 21-Jul-86 09:13:16 EDT
Article-I.D.: ucbvax.8607211509.AA12215
Posted: Mon Jul 21 09:13:16 1986
Date-Received: Mon, 21-Jul-86 21:34:03 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jas@proteon.com
Organization: The ARPA Internet
Lines: 35
Approved: tcp-ip@sri-nic.arpa

I'll answer two open questions at once here.

The 802.2 connection oriented features probably really exist so that IBM
could run SNA on "their" 802.5 Token-Ring Network. SNA absolutely
requires a reliable data-link layer, this is essentially the only level
where there are any data integrity features in the SNA architecture.
That's why IBM's Token-Ring board has a complete 802.2 connection
oriented (VC) in the firmware of their PC board, along with an extended
XID frame for SNA.

I don't think that using a VC data link for IP is going to help you on a
LAN. First of all, nobody's going to manage to write a 6-10 megabit/sec
802.2 VC layer. Secondly, stacking VC layers does not always work well.
Third, this is not really the way TCP/IP was intended to be used. (Of
course, on slow nets like the ARPANET, the VC code does not get in the
way.) Fourth, the sequence numbering is only modulo-128. This can get
consumed rapidly by tinygrams, and you will go into senquence number
wait.

On the issues of single ACK in TCP, this has to do with degenerative
congestion when packets are being dropped. The sender sends 5120 bytes
in ten TCP packets. The second one gets dropped due to congestion. The
ACK of the first comes back. The last 8 packets get retransmitted. The
second one (orignal fourth) gets dropped due to congestion. Repeat. What
we have is a tendency towards instability when packets start getting
lost. Note that the congestion is getting worse for eveyone due to this,
since packets are being sent many extra times. This sort of problem is
why people are developing protocols with what I call "ACK vectors", such
as NETBLT at MIT, and NETEX from Network Systems. These provide the fate
of the last 'n' packets in ACKs, rather than a ACK-point. Only the
dropped packet gets retransmitted in these protocols.

					john shriver
 					proteon
-------