major changes to 1822

21 Mar 1986 21:35:40 PST

I agree that RFC 979 describes some very significant changes to the
Interface Between a Host and an IMP. I agree that it is important for
anyone that is responsible for an ARPANET or MILNET network interface
driver to look at this very carefully. It may also have impact in
other parts of the network code in ARPANET and MILNET hosts.

I am also concerned about the removal of the "uncontrolled" message
capability. Back in the olden days this was called a "type 3"

This feature was introduced in to the ARPANET to support packet
speech. A key aspect of real time packet speech is that low delay is
important, and even more important is low variation in delay. Speech
can tolerate the loss of a few packets now and then. The reliability
mechanisms (timeout and retransmission if no ack) introduce far too
much variation in delay. It is true that very little use has been
made of type 3 messages in recent years. However, with the recent
work in multimedia protocols turning to focus on a multimedia real
time conferencing system, there may well be the need for type 3 again.

The notion that type 3 is only going away temporarily is a bit
misleading. Type 3 goes away in the move from release 6 to release 7,
and something come in in the move from release 7 to release 8. The
time between theses moves could well be over a year (based on the
recent history of such moves). And the something that comes back is
supposed to have a multipacket mode, which implies a reassembly
timeout. (The messages that time out are ones that wouldn't be
delivered anyway, so as long as there are enough buffers that
subsequent messages get through while while the timeout is ticking
away, it may be ok.)

I got a bit confused about all these connections. In 3.1.3 about
AHIP, it says that the host can specify the connection in the handling
type field. In 3.1.4 about Standard X.25, it says something about
link numbers mapping to different connections. Maybe these are
different types of connections? If not, what gives, if so, how does
Standard X.25 control the type of connections discussed in 3.1.3?

It seems to me that the new end to end put a lot of faith on the new
congestion control. Based only on the new end to end it seems that
each host could have in play in the network up to 127 messages (of 8
packets each) on each of 256 connections to each other host. With
only 200 host on the net, each host could give its IMP over 50 million
packets to deliver before being blocked. Clearly this is wrong. I
must have missed something. It is going to be a lot harder for a host
to avoid being blocked than it is now (since the blocking condition
will be harder to calculate or predict). OOPS, did i see a note that
the new congestion control does not go in till release 8? If so, what
stops this potential overloading?

There sure is a lot of good stuff in this new end to end, especially
getting the X.25 support up to snuff, and the interoperability between
AHIP and Standard X.25 hosts.

Maybe it would help to have more publication of plans and ideas about
changes to the Host-IMP interface in the early stages. Then there
could be more feedback about priorities and how plans for one part of
the system might interact with plans for another part (e.g., type 3
vis a vis multimedia conferencing).


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