Re: A couple of simple questions.


Andy Malis (malis@CC5.BBN.COM)
Mon, 23 Nov 87 10:10:11 -0500


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,
Andy



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:56 GMT