Re: major changes to 1822


Andrew Malis (malis@bbnccs.ARPA)
Mon, 24 Mar 86 10:20:56 EST


Jon,

I have already discussed the uncontrolled messages, in my reply
to Mark's message. I would like to add that when the datagrams
are implemented in Release 8, any datagrams containing 128 or
fewer octets will be sent as a single packet, and these should
present the same delay characteristics as the current
uncontrolled messages. I would also like to add that you only
get the low variation in delay when the network is relatively
uncongested, which was always the case in the old ARPANET when
the packet speech work was actively underway. As you probably
know, the old ARPANET was only ever using a small percentage of
its total capacity. The current ARPANET is being run at a higher
utilitization than was the combined ARPANET/MILNET just before
the split, and that was more highly utilitized than the ARPANET
of the 70s and even early 80s. At the current utilization
levels, I would want to run a series of experiments before I
could predict the delay characteristics of even the old
uncontrolled messages, and their current suitability for speech.

On congestion control:

Store-and-forward congestion control is what is scheduled for
Release 8. It is designed to allow the store-and-forward
subnetwork to feed back to source PSNs congestion information
concerning the route a packet will take, and to control the rate
at which packets are submitted into the subnet. The source PSNs'
end-to-end, in turn, will use this feedback to control the rate
at which hosts are allowed to submit traffic to the net. This
congestion control is necessary before we begin any widespread
use of datagrams.

Release 7 includes end-to-end congestion control. This monitors
the availability of resources in the source and destination PSNs
of a traffic flow, and, if necessary, slows down the rate of
submission from a host if it is causing congestion (lack of
resources) in either the source or destination PSNs. In each
PSN, there are configuration parameters the amount of resources
that each host can use (so that one host cannot saturate a PSN
and lock out other hosts). So, while the new EE contains the
capability for hosts to create a large number of connections,
they will only be able to submit unacknowledged traffic until
they begin to congest either source or destination PSN. At that
point, they will be slowed down by using whatever means in
available in the host-IMP protocol. For X.25 hosts, this
includes witholding acks and issuing RNRs; for AHIP hosts, this
may mean issuing incompletes or blocking.

It is true that since the PSN is now willing to buffer the ninth
(or tenth, or ...) outstanding message on an AHIP connection, it
will be much harder to predict when a host will be blocked.
However, hosts should be blocked LESS often than before, since
the old EE would also blocked if faced with a resource shortage.

On connections:

The new EE has one type of connection, and is now allowing more
than one connection to exist simultaneously between AHIP hosts
(or between an AHIP host and a Standard X.25 host) where the old
EE only allowed one. This gives these hosts the same
cababilities that Basic X.25 hosts enjoy, and is meant to be for
for the hosts' benefit (especially for Standard X.25 hosts, which
can now use a separate LCN for each logical flow to an AHIP host,
rather than being forced to multiplex all of its traffic over the
same LCN).

Andy



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