guru@wuccrc.UUCP (Guru Parulkar) (11/21/87)
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. However, I haven't seen any reference or RFC announcement which describes this protocol. Maybe, I missed it. Could somebody tell me if there is any reference on that. Or is this protocol BBN's proprietrary. 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). I believe this protocol is essentially a connection oriented which means we have a situation where a connection less internet protocol IP sits on the top of a connection oriented protocol. Is it possible that in this situation the overhead of connection management does not have good "payoffs" at IP level or layers above that ? I remember Dr. Dave Mills saying something on similar lines in one of his classes at Delaware. (Maybe, I misunderstood what he was trying to convey.) I need to understand this issue better, and I would appreciate if somebody could help me with this. Thanks! -guru parulkar wuccrc!guru@uunet.uu.net or Dept of CS parulkar@udel.edu Washington Univ St. Louis
Mills@UDEL.EDU (11/22/87)
Guru, Yes, ARPANET is now and has been a connection-oriented network, but with dynamics and route-binding mechanisms usually friendly to frisky datagram service. Sometimes, like in the recent case of an X.25 access problem which resulted in destructive virtual-circuit thrashing, the more liberal of us buzzards may grumble a bit or two, but not because virtual circuits, route binding or flow mechanisms are inherently bad. 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. Andy Malis described the new End-End Protocol in RFC-979. Dave
Lixia@XX.LCS.MIT.EDU (Lixia Zhang) (11/22/87)
I'll leave the version-7 description to BBN people, and only say a few words about your second question (about the PSN-PSN protocol, or IMP-IMP protocol as it used to be called). It is a link layer protocol providing reliable datagram deliveries (i.e. every packet will be delivered, but possibly out-of-order). It has nothing to do with connection concept at the network layer. ARAPNET 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. 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. ARPANET opens an end-to-end connection to deliver data between two hosts (which can be IP gateways), and blocks the interface to the host whenever the PSN(IMP) runs out of the resources (buffers, control table entries, whatever). And that is why packets always get lost at the gateways: the IP gateway has no mechanism to stop incoming packets, so it has to drop them when they can't be forwarded. Lixia -------
martillo@ATHENA.MIT.EDU (11/22/87)
Hi, my wife and I and a friend (Diane Rahe who is a hardware engineer in my group at Prime) are going out to dinner (probably in Chinatown) sometime between 6 and 7. Would you be interested? Just send me mail. I cannot be reached by phone. Yakim Martillo
sy.Ken@CU20B.COLUMBIA.EDU.UUCP (11/23/87)
Hi, my wife and I and a friend (Diane Rahe who is a hardware engineer in my group at Prime) are going out to dinner (probably in Chinatown) sometime between 6 and 7. Would you be interested?... You're going to need a reservation for several thousand at least... -------
malis@CC5.BBN.COM (Andy Malis) (11/23/87)
I would like to add a few comments to the "simple questions"
messages, in the order that I received them.
From: Guru Parulkar <wucs1!wuccrc!guru@UUNET.UU.NET>
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 <Lixia@XX.LCS.MIT.EDU>
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,
AndyMills@UDEL.EDU (11/23/87)
Andy, Did someone say Chinese? If you an Mr. Martillo can wait until the INARC Workshop at BBN on 17-18 December, we can bring the whole gang. Our advertising department couldn't pass that one up. Dave