9 Jan
2013
9 Jan
'13
8:29 p.m.
On Jan 9, 2013, at 9:06 PM, Peter Lothberg wrote:
Keep in mind, on here you've got 600MHz Alphas (performance like a
2.5GHz x86 box but with better I/O) and you've got emulated VAXen
running on 700MHz ARM processors...which do you think will be faster? ;)
-Dave
I think we are more limited by the protocol itself, they where not
thinking gigabit networking, packet size and number of outstanding
packets (window size) is a limitation here that processor speed can't
help. Remember, this is pre-tcp, pre van j protocols, and maybe to
heavily influenced by X.25. (Connection oriented conection less, or
was it the other way around..)
Whoa, not so fast. Some people might not appreciate it if you compare DECnet with X.25.
A bunch of TCP/IP technology actually comes from DECnet. There's OSPF, of course
(which came from OSI IS-IS, which came from DECnet Phase V). Also, a fair amount of
congestion control work started at DEC. That's why there is the "DEC bit",
the nickname for the congestion notification flag that figures in a number of congestion
control schemes (originally added in DECnet based on the work of K.K. Ramakrishnan). For
that matter, some of the "slow start" congestion control approaches also were
originally done at DEC, by Raj Jain.
Connection oriented and connectionless: DECnet in that respect (on Ethernet) is exactly
like TCP/IP. Yes, point to point datalinks are connection oriented; that was necessary
in the early days (not for IP since it only used expensive links). And besides, it
doesn't cost much there.
One example why you shouldn't mention X.25 is that NSP, like TCP, uses a 3-way
connection establishment handshake. X.25 has a two way handshake, a serious design error
it copied from HDLC.
In some ways DECnet is better than TCP, for example the application addressing being
separate from the NSP connection endpoint addressing (object numbers vs. connection
numbers), where TCP uses the same for both. As a result, connection lookup is
dramatically more efficient in NSP.
You're right that NSP has limited window size compared to TCP. More precisely, TCP
with window scaling. If DECnet had lived long enough, it would presumably have had a
window scaling option too.
Another example is, how do DECnet figure out the MTU? It takes the
max packet size of the two endsystems and uses the lowest of the two
numbers. If there is a node in the middle with a smaller MTU it will
retransmitt for ever. MRC (rip) ported DECnet to the DEC2020, where
for reasons you only have one page (512words) to store 4 packets from
the KMC/DUP. So it's not 576, it's 360 (something).. So having a 2020
with two serial ports and DECnet acting as a routing-4 node broke most
connections...
True. DECnet is a private network technology, so the assumption is that it can rely on
correct management of the routers. And MTU size is one of the things assumed to be done
right. DEC's network for a long time used 576 as its MTU; I would assume even a 2020
can be set that way, how else could such a node have existed on the DEC Easynet?
paul