Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!uwvax!uwmacc!uwmcsd1!ig!jade!ucbvax!CC5.BBN.COM!malis From: malis@CC5.BBN.COM (Andy Malis) Newsgroups: comp.protocols.tcp-ip Subject: Re: A couple of simple questions. Message-ID: <8711231559.AA02850@ucbvax.Berkeley.EDU> Date: Mon, 23-Nov-87 11:01:27 EST Article-I.D.: ucbvax.8711231559.AA02850 Posted: Mon Nov 23 11:01:27 1987 Date-Received: Thu, 26-Nov-87 01:51:23 EST References: <12352652943.15.LIXIA@XX.LCS.MIT.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 102 I would like to add a few comments to the "simple questions" messages, in the order that I received them. From: Guru Parulkar In the last few weeks, there has been a number of messages about PSN version 7 release and a new end-to-end ARPAnet protocol. ... As Dave Mills has already pointed out (thanks, Dave) I wrote RFC 979 in March of '86 to describe the external functionality of the new EE in PSN 7.0. It's still accurate for PSN 7.0, but please read anything in there concerning future PSN releases with a grain of salt. This was written some time ago, and plans have a way of changing, as I'm sure you're all aware. One question that I wanted to ask for a while is about the "connection oriented" nature of ARPAnet's link level (or PSN - PSN protocol). ... You are absolutely correct - IP datagrams are being sent over internal connections between endpoint PSNs (and, in the case of IP over X.25, the connections go all the way back to the hosts). There are a number of reasons that this is done (including history - the predecessor to TCP, NCP, depended upon this reliable service from the subnet), but the most important is that imposing per-connection restrictions on the host traffic is currently the only way the PSNs have to protect themselves and the network (without dropping packets) from being completely overwhelmed by offered load. Whether the PSNs SHOULD drop packets or not when supporting TCP/IP-based applications is another question altogether (and one I would rather not get into right now). As an aside, there are many non-TCP/IP based applications that run on BBNCC PSN networks, and these require the reliable connection-based service provided by the PSN. Even the per-connection restrictions aren't enough to allow the PSNs to push back, when necessary, on source hosts. Because of this, we have been working on congestion control for the PSNs. Only after congestion control has been deployed can we start thinking about implementing some sort of non-connection-based service for the ARPANET and other TCP/IP nets. From: Mills@LOUIE.UDEL.EDU Sometimes, however, the choice of resource allocation and binding strategies in ARPANET (and public packet nets) suggest the designers had in mind a few number of large flows between hosts attached to the network, rather than a large number of small flows between gateways, which seems to be what the ARPANET is evolving to. You are mostly correct. In the "good old days" of small IMPs, when we only had on the order of 64 connection blocks on an IMP, we really hadn't designed for the sort of traffic that you now see on the ARPANET between gateways. However, we tried to adjust our algorithms somewhat to make the new EE more general for the different sorts of applications we see now see running on PSN networks. As a result, the new EE can support up to 2000 simultaneous connections on a C/300 (which are becoming more common on the ARPANET) and 512 on a C/30 (which has less memory and CPU horsepower). From: Lixia Zhang ARPANET runs a DATAGRAM protocol internally, but provides a virtual-circuit interface to the host by a reliable network end-to-end (i.e. between entry-exit IMPs) protocol. You are correct, except for one small point - your use of the word DATAGRAM may suggest to some that PSNs may be willing to drop packets if necessary. This is not the case - the only time packets are lost in the subnet is if a PSN crashes or, because of network congestion, a PSN cannot accept a packet from its neighbor in 32 transmission attempts from the neighbor. The old EE could not recover from such packet lossages. The new EE has source retransmissions, and can recover from such internal packet loss. Therefore some of your words are still correct -- unreliable IP runs on top of the reliable ARPANET, and indeed causes high overhead in many cases. We've also worked hard on the new EE to reduce this necessary overhead. For example, we've cut down on the packet header size and can send the data for the first message over a connection as a part of the connection open request. From: martillo@ATHENA.MIT.EDU Hi, my wife and I and a friend ... are going out to dinner (probably in Chinatown) sometime between 6 and 7. Would you be interested? Sounds good. I'm partial to Carl's Pogoda and the Golden Palace. Regards, Andy