ACC 5250 under Ultrix 1.1

Chris VandenBerg (chris@ACC-SB-UNIX.ARPA)
Wed, 21 Sep 88 12:58:48 PDT

>From gary Wed Sep 21 12:34:42 1988
Received: by ACC-SB-UNIX.ARPA (5.51/4.7)
        id AA00536; Wed, 21 Sep 88 12:34:35 PDT
Date: Wed, 21 Sep 88 12:34:35 PDT
From: gary (Gary Krall)
Message-Id: <8809211934.AA00536@ACC-SB-UNIX.ARPA>
To: chris
Subject: 4020 Flames
Status: R


I wanted to clear up a few points that were raised in your
recent posting to the tcp-ip discussion list regarding the use
of Transparent Gateways, and their implications on the DDN.

First off, I thought you did a great job explaining how a
Transparent Gateway works. As you discribed the ACS 4020 uses
the logical host field to map Ethernet hosts onto the DDN.

>There are several problems with this arrangement. First and
>foremost, RFC 1005 (May 1987) contains a suggestions for
>rearranging the 32 bit IP address. This suggestion, if adopted,
>would render the transparent gateway router useless. This is
>why the Milnet manager is discouraging the use of this
>addressing scheme.

Before we began work on our Transparent Gateway we held meetings with
BBN, DCA and consulted with key members of the Internet Activities
Board to discuss the approach we were considering. One of the
results of those meeting's was our inclusion in RFC 1009
(Requirements for Internet Gateways) as a viable alternative to
EGP-style gateways.

The other important point is that RFC's are "Request for Comments"
and it does not necessarily follow that "suggestions" will become
"implementations". We have a relatively large number of units installed
on the network due to the appeal of this functionality. This being the case
one of the concerns with implementing RFC 1005 is the potential
impact on those sites. Secondly, it does not necessarily follow that
if RFC 1005 is adopted, "it would render the transparent gateway
router useless." In fact it might pose some problems in terms of the
number of hosts we can support (which is currently 49) but the utility
of the device is still available.

>Without being published in the NIC's host table, it is difficult
>to receive electronic mail without the IP address as the distant
>end will have no way of knowing which PSN and port the host is on.
>This is not a problem if the DOMAIN system is employed.

Curt, I just did a "whois" and got host info and an IP
address back from the NIC. This is the electronic mail host for your
site, Ft. Huachuca. We've had a Transparent Gateway operating down there
for about a year and a half now and, as a matter of fact, you are
reading this message courtesy of our unit. I've never had to know the
IP address, I just specify the name. The point is that a)
it is fairly easy to edit host tables both in your local environment
and at the NIC and b) as the NIC does not want to manage all the
growing host tables the DDN has mandated the use of the Domain system
which, as you pointed out, alleviates the problem.

>First, is anyone using this currently? I know of the definition
>of how it is to be done on the X25 connections to the net.

>Currently, the HOST.TXT file shows only 3 of the 1727 Milnet hosts
>using this addressing format. These three machines are special
>purpose Sun work stations with only a single user per machine.
>There are many others, they just are not published.

Please see my previous paragraph and, again, the point is that not
everyone using a ACS 4020 has actually advised the NIC of their
host address simply for the fact that they have a limited community
that needs to send/receive mail or they are using the DOMAIN system.

>There is another concern with using a transparent gateway. Some
>gateways may or may not fully participate with the Internet Control
>Messaging Protocol (ICMP) [1]. The ICMP is concerned with network
>flow control. A transparent gateway which does not fully
>participate with ICMP may choke the PSN, or it may not inform
>the host that the distant end is dead [2].

I'd like to quote from a paper that Gary Krall, ACC's Director of
Marketing and Keith McCloughrie, now with The Wollongong Group, wrote
for Connections Magazine awhile ago:

Flow Control

"Data transmission between the ACS 4020 and the DDN-X.25 network is
flow-controlled at both levels 2 and 3 of the DDN-X.25 protocol. In
contrast, there is no flow-control on transmissions between the ACS
4020 and Hosts on the Ethernet. This, of course, is typical of an
Ethernet environment and of the datagram concept of an IP-network,
where guaranteed ordered delivery requires the use of an end-to-end
transport protocol (e.g., TCP). Some assurance, however, is needed that
a) Ethernet Hosts do not repeatedly overrun the ACS 4020 with more
transmissions than the DDN-X.25 network can absorb, and b) there is a
limit to how much Ethernet traffic, the ACS 4020 can send in one burst
to a Host.

These assurances are provided through the availability of a large
amount of buffer space in the ACS 4020, and by the use of flow-
control in the Host's level 4 (and higher) protocols. For example, if
TCP is used for the majority of transmissions, then the end-to-end
flow control on TCP connections provides a window size specifying
the maximum amount of data to be in transmission on each connection.
This window size is dynamically adjusted by the receiving TCP
implementation according to its current buffer space limitations.

In the ACS 4020 to Host direction, the Host's assurance of being able
to take the maximum burst of traffic, is that the size of such a burst
is limited by the aggregate of all window sizes, and that the Host
itself controls these.

In the other direction, the provision of 1.5MByte of buffer space
assures that the ACS 4020 is not repeatedly
overrun. With this amount of memory, the capacity to buffer data
which the DDN-X.25 network can not yet absorb is estimated at 400
TCP connections (assuming an average window size of 1KBytes).

Nevertheless, congestion can cause TCP retransmission timers to expire
resulting in additional IP datagrams being received by the ACS 4020.
Correctly implemented TCPs will dynamically respond to this by
slowing their rate of retransmission. However some means of limiting
the number of queued datagrams is required to cater to "rogue" TCP
implementations. This means is provided for by the use of the
"time_to_live" field in the IP header. As specified in the IP
specification this field must be decremented every second it is queued
in the ACS 4020, with the datagram being discarded if this field
reaches zero.

As mentioned above, data transmission between the ACS 4020 and the
X.25 network is flow-controlled at both levels 2 and 3.
Note that flow control at X.25 level 3, provides independent
flow control for each X.25 logical address. Thus, independent flow
control for individual Ethernet hosts is obtained if a unique X.25
logical address is assigned for each. This would prevent one "rogue"
TCP implementation from starving all the others of all service."

>Why anyone would want to use this type of gateway is beyond me. I
>really would like to hear some good reason to use it. I may not be
>aware of some special feature about remaining a Class A host. My
>understanding is folks like to use them as they believe this is the
>only way to do X.25 type multiplexing.

Curt, you have listed many of the disadvantages of Transparent Gateways.
Let me quote again from the same article:

Advantages of Transparent Gateways

"A Transparent Gateway provides better performance since there is less
overhead traffic on the congested X.25 link. For example; a
Transparent Gateway requires no exchange (i.e. both directions)
of periodic routing table updates and status messages. It only
requires routing information to be received for destinations currently
being used, and only when routing changes as is the case for
directly attached hosts.

Transparent Gateways provide flow control on a
source-host/destination-host pair basis rather than on a
destination-host-only basis. Separate X.25 virtual circuits are
established for each X.25 logical address assigned to one or more
of the Ethernet hosts. Thus, the use of multiple logical addresses
provides the additional flow control rather than having all packets
lumped into a single virtual circuit as would be established by an
IP Gateway. Thus, the few packets of an interactive connection from
one Ethernet host would not be delayed by the many packets of a bulk
transfer from another Ethernet host.

Transparent Gateways do not implement any of the current Gateway
protocols, which are currently under review and are subject to
change (see revised version of RFC 985 and other proposed changes
such as "Son-of-EGP").

The use of Transparent Gateway's eases the problems associated with
the increasing number of active networks by not requiring an extra
network number for an isolated Ethernet.

Transparent Gateways will also make it less likely for hosts on
the Ethernet to suffer loss of connectivity to distant networks
due to lack of routing table space, since space will
not be required for a network number for the Ethernet.

Finally, the use of multiple Transparent Gateways between an Ethernet
and a DDN X.25 network provides the capability to load-level the traffic
being exchanged between the two networks.
This load-leveling occurs as a result of the necessary virtual
circuits between Ethernet hosts and X.25 hosts being spread
across the multiple Transparent Gateways."

> Hope this helps Barry,
>Curt Vincent
>Army Computer Engineering Center
>Army Information Systems Engineering Command
>Fort Huachuca, AZ 85613-7300

I guess it's like anything in life, there's really no free lunch. We've
found many applications that are well-suited to the capabilities of
a Transparent Gateway, but it's not a solution for all sites and we
don't represent it as such. It is, however, a cost-effective way for
many sites to gain connectivity to the resources of the DDN and other

Chris VandenBerg

Usual disclaimer, discussion (and even flames) welcomed.

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