<NIS.NSF.NET> [IMR] IMR87-06.TXT
Westine [Page 1]
~
JUNE 1987
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the participating organizations.
This report is for research use only, and is not for public
distribution.
Each organization is expected to submit a 1/2 page report on the first
business day of the month describing the previous month's activities.
These reports should be submitted via network mail to Ann Westine
(Westine@ISI.EDU) or Karen Roubicek (Roubicek@SH.CS.NET).
BBN LABORATORIES AND BBN COMMUNICATIONS CORPORATION
---------------------------------------------------
INTERNET GATEWAY RESEARCH AND DEVELOPMENT
Mike Brescia and Bob Hinden attended the June Satnet meetings in
Norway.
We completed the IP reassembly code for the Butterfly gateways and
installed it in the six Satnet gateways. This code allows EGP
updates to be fragmented and reassembled over the Satnet, allowing
full exterior routing despite the 256 byte MTU. This will also
allow the Butterfly Gateways on Arpanet and Milnet to handle EGP
updates larger than 1006 bytes from the LSI-11 EGP servers, when
Westine [Page 1]
Internet Monthly Report June 1987
the number of networks and gateways makes this necessary.
We started work on a congestion control scheme for internet
gateways, which is currently in the research and definition stage.
WIDEBAND NETWORK
BSAT software Release 5.3 was distributed to the Wideband Network
sites. This release modifies some aspects of internal processing
flow within the BSAT's satellite channel interface module. The
effects of the modifications include increased priority for stream
messages contending with datagram messages for BSAT processing
capacity and greater independence between the channel interface
module and the BSAT host modules.
BSMI boards were installed at the DCEC, RADC, and Ft. Monmouth
Wideband Network sites. Every network site is now using BSMI
hardware for satellite channel operations.
Personnel from BBN and ISI travelled to M/A-COM Linkabit in San
Diego to participate in a discussion about potential ESI
development work. A number of ESI performance and reliability
improvements and operational problems were discussed. A list of
action items was drawn up which included ESI repair and
performance-related tasks.
SATNET
The SATNET remained stable through the month of June. No new SIMP
hardware or software problems occurred. We are still waiting on
the acceptance of the spare modems from Linkabit before shipping
spare parts to the sites.
Measurement Taskforce work done during the month included:
verifying that the bottleneck between the UCL gateway and Goonhilly
SIMP is no longer present, monitoring SATNET traffic with a finer
granularity, retesting the "multiple of 8" bug patch, and
remeasuring the overall throughput of the SATNET.
Claudio Topolcic, Karen Seo, John Leddy, Mike Brescia, and Bob
Hinden attended the SATNET/Infrastructure and SATNET Measurement
Taskforce meetings at NTA-RE, Oslo, Norway on 6/23-6/25.
Steve Blumenthal@VAX.BBN.COM
Westine [Page 2]
Internet Monthly Report June 1987
ISI
---
Internet Concepts Project
Jon Postel and Bob Braden completed RFC 1009, "Requirements
for Internet Gateways."
Six RFCs were published:
RFC 1007: McCoy, W., "Military Supplement to the ISO
Transport Protocol".
RFC 1008: McCoy, W., "Implementation Guide for the
ISO Transport Protocol".
RFC 1009: Braden, B., and J. Postel, "Requirements
for Internet Gateways."
RFC 1012: Reynolds, J.K., and J. Postel, "Bibliography
of Request for Comments 1 through 999.
RFC 1013: Scheifler, R.W., "X Window System Protocol,
Version II Alpha Update - April 1987."
RFC 1014: Sun Microsystems, Inc., XDR: External Data
Representation Standard
Ann Westine
Greg Finn is currently examining how resistent network
protocols are when under attack. If we assume software error,
hardware error, or malicious attack at a single network
router, then what damage can occur to the network as a result?
ARPANET SPF, Internet GGP, hierarchic, and Cartesian protocols
are being examined to determine how attack resistent they are
and how they might be augmented to improve resistence.
Annette DeSchon made a number of updates to the XDE Internet
protocol software which runs on the Xerox Dandelion
workstation. Some of the changes are as follows:
- The ISI Domain Name Resolver has been merged with the
latest 1.1 protocol versions.
- In FTP, the PORT command has been implemented. This
improves FTP's performance quit a bit, solving the problem
in which an initial transfer was followed by much slower
subsequent transfers. In addition, illegal FTP responses,
which are occasionally generated by a 4.3 FTP server in
Westine [Page 3]
Internet Monthly Report June 1987
response to a LIST request, are now displayed. Several
bugs which have been causing the tool to hang have also
been fixed.
- In TCP, the number of pages used for buffering have been
increased. This allows TCP to work better with the buffer
size set to 1500.
- In the INSpyTool, Susie Armstrong's latest improvements
to the NSSpyTool have been merged with ISI's version.
In addition, the INSpyTool now displays the headers on
broadcast packets. Several minor display bugs and
filtering bugs were fixed as well.
These updates have been distributed to various universities
who participate in the Xerox University Grant Program.
Greg Finn & Annette DeSchon
Multimedia Conferencing Project
Work has begun on extending the packet video conferencing
system from a point-to-point connection between two sites to
be a multipoint connection among two or more sites. Initially
a fake video source will be used for the third site since only
two copies of the video hardware currently exist, but this
will still allow a complete test of the protocols.
Brian Hung has modified his program for the IBM-PC AT to scan,
reduce and display the documents at more than twice the speed
of the old version; and in order to see precisely the window a
user has defined, the program now draws a border around the
window which is to be clipped. Currently the program is not
able to generate a message containing an entire bitmap. Joyce
Reynolds continues to exchange Diamond Multimedia Mail between
ISI and outside sites. Steve Casner attended the first meeting
of the combined DSAB User Interface Task Force and IAB
Applications Task Force, at Stanford University, 24-26 June
1987. Steve Casner attended the Wideband Network Improvements
meeting in San Diego, 19 June, 1987.
Steve Casner, Brian Hung, and Joyce Reynolds
NSFNET Project
Annette DeSchon continued development of a background file
transfer program, which will allow a user to submit a request
for a reliable file transfer to take place in the future. A
preliminary version of this program, which uses the third
Westine [Page 4]
Internet Monthly Report June 1987
party or "server-server" model described in RFC 765, is
currently being tested on a Sun workstation.
Bob Braden did a major cleanup on the SUN interface to NETBLT,
and began work on embedding NETBLT into the BSD FTP User
("ftp") and FTP Server ("ftpd") programs. Completion of this
work requires updates to the NETBLT user interface, which Mark
Lambert (MIT LCS) will shortly finish. He also worked on a
draft RFC concerning selective acknowledgments in TCP.
Bob Braden and Annette DeSchon
Supercomputer and Workstation Communication Project
Alan Katz finished an evaluation of equations in Interleaf's
UPS system. Also, I began a study for an "Intelligent
Communication Facility" which would allow users to connect the
output of a program running on one machine to the input of a
program on a different machine.
This facility would be very much like using pipes together
with "rsh" in the Unix world, except that the pipes will be
typed (contain a stream of data of a particular type) and the
system will not be particular to Unix. The data types in the
pipes will probably be X409. It is intended that a user could
"patch together" various programs running on various machines
without having to modify these programs (to the extent this is
possible).
Alan Katz
MIT-LCS
-------
No report received.
Lixia Zhang (Lixia@XX.LCS.MIT.EDU)
MITRE Corporation
-----------------
The objective of the MITRE Internet Engineering program is twofold:
1) to address internet level performance issues for the DoD
internet and 2) to address the interoperability between the DoD and
OSI protocol suites as support for a planned transition from DoD to
OSI protocols. To support these objectives, the following work was
accomplished this month:
Westine [Page 5]
Internet Monthly Report June 1987
1. Internet Performance Measurements.
The baseline performance experiments with different interfaces, and
packet size and delay have been presented at previous Internet
Engineering Task Force meetings. We now are extending the
measurements into the internet area over 1 and 2 gateway hops.
2. Congestion Control Experimentation
The second phase of the local net and stub gateway simulation model
is complete. The additions to the model are as follows:
a. Autoregression techniques to estimate round trip
times in TCP connections and least square estimation
of autoregression parameters.
b. Van Jacobson's slow start method for TCP connections.
c. John Nagle's TCP window constriction on Source
Quench receipt.
d. Soft quench mechanism at the gateway.
A draft user manual for the simulation model will be delivered to
the sponsor in July.
3. FTP/FTAM Application Bridge
The FTAM to FTP connections have been tested and demonstrated; the
FTP to FTAM software has been coded and is being tested. This
bridge uses a combination of the Northrop ISODE and SUNLINK/OSI
software, and SUN DoD protocols to form a dual protocol host to
support the bridge. A Design and Implementation Plan is in peer
review and will be delivered to the sponsor in July.
4. VTP
We continue to develop a Basic VTP implementation and will deliver
a Design and Implementation Plan to the sponsor in July. We also
are very active in the standards developments of VTP and will be
contributing to the redesign of the state table changes in the
protocol specifications defined at the ISO TC97 SC 21 meeting in
Tokyo.
5. User Authentication and Access Control
The model is in the final stages of development and a design plan
for the model has been distributed throughout the government
community for comment. We are participating in the authentication
and access control working groups of the SDNS program and ANSC
X3T5.1.
Westine [Page 6]
Internet Monthly Report June 1987
6. Landmark Routing
The Landmark Hierarchy Model document will be delivered to the
sponsor in July. Work continues on developing algorithms to test
the model and to define criteria for a testbed environment.
7. Name Service
We are working with the NIC in reference to developing a body of
RFC documentation for Name Domain use in the MILNET. We also are
participating in the NBS working group for Directory Service.
Ann Whitaker
NTA & NDRE
----------
No report received.
ROCKWELL
--------
Jim Stevens released a SURAN technical note about route tracing
that includes ideas applicable to IP options or ICMP. The document
is SRNTN 49, "Journey and Route Tracing", and is available to
government agencies and their contractors from the Defense
Technical Information Center (DTIC), Cameron Center, Alexandria,
Virginia 22314.
John Jubin (Jubin@A.ISI.EDU)
SRI
---
1. A paper entitled "Research in Information Exchange
Representations and Layered Software Architectures for C3
Systems" was presented at the JDLC3 conference at Ft. McNair
in Washington, DC on June 18. The paper discusses the
requirements for better software architectures and design
principles that are necessary for complex, evolving C3 systems
in order to maximally utilize multi-vendor hardware and
software.
2. At the same time, The Experimental Multimedia Collaboration
Environment (EMCE) and SITMAP software was shown at the AFCEA
conference in WDC running on Sun 3/260 hardware. A three
workstation configuration connected by an Ethernet was used to
Westine [Page 7]
Internet Monthly Report June 1987
demonstrate the two software suites developed under contract
for NOSC and CECOMs. These systems are illustrations of the
principles and difficulties encountered in implementing the
techniques defined in the paper. Specific capabilities shown
are involved in the situation assessment and monitoring phases
of the C3I process, and include showing unit locations with
icon overlays on high precision digitized color maps;
accessing additional information by graphical references;
real-time voice, pointer and program command exchange over the
Ethernet, and a module set of Interactive Graphical Tools
based on the Structured Display File representation developed
by Keith Lantz at Stanford. Specifically, the low delay
requirements of realtime multimedia interactions in such
layered highly modular software systems was illustrated and
discussed.
Jim Mathis (Mathis@KL.SRI.COM)
UCL
---
Jon Crowcroft and Peter Kirstein attended the SATNET/Infrastructure
and ICB meetings in Oslo.
UCL in conjunction with NTA and BBN has been making a series of
measurements of IP and TCP performance over SATNET and the ARPANET.
Preliminary findings confirm earlier work by Peter Lloyd are that
current TCPs do not cope well with high delay networks where
packets are actually dropped in any significant numbers. A simple
example of this is a pure SATNET route which can support
approximately 63kbps IP throughput, but only 10kbps TCP throughput.
The TCP throughput falls to less than 4kbps when adding an ARPANET
hop to the measurement path.
The ISODE FTAM is now running over two different X.25 networks as
well as on TCP/IP. Steve Kille has made a preliminary specification
of the PP (X.400) mail system interfaces in ASN.1.
The Admiral megastream network is being used for fast (500kbps)
access to the Crays at the University of London Computer Centre
(ULCC). An RPC to JTMP (JNT version of JTM) relay runs on a
microvax at ULCC and forwards calls to the Cray/Amdahl cluster.
John Crowcroft (jon@CS.UCL.AC.UK)
Westine [Page 8]
Internet Monthly Report June 1987
UNIVERSITY OF DELAWARE
----------------------
1. Development continues on the Dissimilar Gateway Protocol
(DGP). A developmental model has been worked out which
provides type-of-service routing and selectable routing
constraints in a fixed hierarchy. This model does not require
slope/intercept data from all gateway interfaces, but does use
source routing (where required) and requires DGP neighbors
from different systems to reside on the same net. A technical
note and briefing are now in preparation.
2. The new fuzzware distribution for the NSFNET Backbone
installed early in the month performed very well; however,
observations during its first two weeks of operation suggested
certain improvements which could further improve performance
under the frequent conditions of heavy stress. Subsequently
the preemption policy was changed to (a) insure an input
buffer is always available, (b) provide equal access to buffer
resources for all input lines and (c) provide uniform
preemption rates over all output lines. The new policy was
installed near the middle of the month, with result that the
drop rate for the network as a whole fell dramatically while
the traffic carried increased substantially.
3. After two weeks of observation with the new preemption policy,
it became clear that (a) the internal datagram-aging (TTL)
mechanism in the fuzzballs was not always working properly and
(b) the preemption policy should be further granularized to
provide equal access to buffer resources for all original
senders (IP source address). Both of these things were fixed
and tested in the backlots at U Delaware and Linkabit and are
now ready for distribution. The latest changes amount to a
full-scale test of the "fair queueing" mechanisms suggested by
John nagle, Lixia Zhang and others at recent INENG task-force
meetings.
4. Initial testing of the newest preemption policy revealed
fascinating insights into the detail mechanisms of typical
path-overload events in the Internet. As expected, only a few
hosts out of many (identified on request) are responsible for
most of these events and the events themselves are brief, but
intense. An event usually involves many tinygrams from the
same hosts, so a new buffer request can result in many of
these being preempted. A preemption is very likely to be
followed immediately by another for the same host. There are
many lessons for the source-quench mechanism here which have
yet to be digested and understood.
5. The network-time synchronization system, which also serves as
Westine [Page 9]
Internet Monthly Report June 1987
an advance warning detector for routing instabilities or
corequakes, has been sounding alarms of increasing urgency
over the last two weeks. During testing of the new preemption
policy it became clear that serious trouble is brewing in the
core gateway system with routes oscillating wildly between
gateways and many instances of broken connectivity. This was
confirmed by direct observation from the INOC of the routing
data base, portions of which were captured and distributed in
a message to the tcp-ip list. At the end of the month the
cause of these problems had not yet been identified.
6. I completed and distributed to INENG and NSF lists, a draft of
a proposed scheme for interworking between routing algorithms
of the same or different autonomous systems. Within a system
the scheme requires both the metrics and the transformations
between them to satisfy certain conditions, which the most
common ones (RIPspeak and Hellospeak) alread do. Between
systems the scheme relies on pre-engineered spanning trees
embedded in an otherwise unrestricted topology, together with
designated primary and fallback gateways for each net in each
system.
Dave Mills (Mills@UDEL.EDU)
Westine [Page 10]
Internet Monthly Report June 1987
NSF NETWORKING
--------------
UCAR/BBN LABS NSF NETWORK SERVICE CENTER (NNSC)
A twelve-month on-line calendar of meetings and conferences of
interest to the Internet community is now available on the CSNET
Info Server. For information on how to use the Info Server, send a
message to <info-server@sh.cs.net> with the following text in the
body of your message:
Request: calendar
Topic: help
The first issue of the NSF Network News has been completed and will
be distributed in mid-July. Craig Partridge, Bill Curtis, and
Karen Roubicek visited JVNC to meet with Sergio Heker and User
Services Manager Vercell Vance. Draft RFCs for the High-Level
Entity Management System (HEMS) were finished, and sent to the RFC
editor but release has been postponed for a few weeks to make minor
changes requested by some vendors. An open workshop on network
management has been scheduled for the first day of the Internet
Engineering Task Force meeting at the end of July.
By Karen Roubicek (roubicek@nnsc.nsf.net)
NSFNET BACKBONE STITES
CORNELL UNIVERSITY THEORY CENTER
Backbone Operations:
42,560,072 packets were delivered to the backbone in May, up 37%
from April.
New software has been installed on all backbone fuzzballs. All
indications are that things are more stable since the upgrade.
Coordination and Interoperability Issues:
Progress on "gated" is coming along slowly, but steadily. A number
of sites have a Beta-release that is being tested at the current
time. Almost all of the features mentioned previously in this
forum have been added. "Gated" will be made available to the
general public after a little more polishing and testing is done.
By Craig Callinan (craig@tcgould.tn.cornell.edu)
UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN
Changes were made to the Cray CTSS IP/TCP to attempt to make it
Westine [Page 11]
Internet Monthly Report June 1987
more neighborly. It now responds to ICMP Source Quenches using the
algorithm of Jon Postel's upcomming RFC. It uses Mills' RFC889
nonlinear SRTT calculation. Also, due to problems with long delays
associated with file transfers to the SDSC Cray, its maximum
retransmission interval can be 4 minutes. Mods to CTSS to allow
arbitrary sized interprocess communications have been installed.
When TCP and the user call library are converted to use the new
features a major bottleneck in the communication path will be
widened.
We are passing around on NSFNET a draft novices guide to Internet
facilities folklore, and hints. The first round of comments is
currently being integrated into the document. It should be ready
for consumption during July.
By Ed Krol (krol@uxc.cso.uiuc.edu)
JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER
prepared: Tue Jun 30 13:43:35 1987
Monthly Report
node name meanttr maxttr meantbf sched_down avail perform
(min) (min) (min) time (%) (%) (%)
--------- ------- ------ ------- ---------- ------ --------
jvncb 107 97 21328 2 99 99
jvncc 37 97 6755 7 99 95
jvncd 35 100 5794 7 99 96
jvnce 26 50 2270 0 98 98
jvncf 24 119 3261 2 99 97
arizona 404 724 10683 0 97 96
brown 68 75 4665 14 99 98
colorado 0 724 21580 0 98 98
columbia 25 215 684 0 96 93
harvard 63 70 8593 1 99 98
ias 10 10 14636 0 99 99
mit 63 70 8593 1 99 98
njit 1729 6519 6169 0 84 83
nyu 21 95 3972 0 99 99
penn_state 52 95 43833 0 99 99
princeton 10 10 14636 0 99 99
rutgers 60 130 5439 0 99 98
rochester 27 95 10948 0 99 99
u-of-penn 40 40 7281 0 99 99
stevens 424 6588 2040 0 83 83
umdnj 701 6510 3355 0 83 83
Total test time (min): 43938
Westine [Page 12]
Internet Monthly Report June 1987
Note that the monitoring is done by one of the "routers" therefore
when the monitoring "router" is down, we have no information of
whether the rest of the network is operational or not.
Also, the tests are performed on the 128.121 address of the
routers, and with the knowledge that our class B address is
subnetted. Thus, when i.e. the tests gives "columbia" "down", it
means to us that: or the gateways are down (physically or the
networking software), or the path to columbia is down, and the path
can only be one (the one determined by the subnetted number that
the "columbia" gateway uses).
The meaning of the terms are:
nodename: the gateway or host on JVNC-NET network (128.121)
meanttr: in minutes, the mean time to recover from the
"down" state to the "up" state. Where "down"
state is when the result of sending "icmp-echo"
packets is no packets return, and the "up" state
is when we receive packets back. Each test is
performed 10 times, every 10 minutes, and
averaged each time.
maxttr: in minutes, the maximum time to recover, from the
"down" state to the "up" state (see above).
meantbf: in minutes, the mean time between failures.
sched_down time: in percent, is the time the gateways/hosts were
"scheduled" to be down, respect to the total time
of test.
avail: in percent, is the time for which the gateways
were available ("up" state) respect to the total
time of test (minus the scheduled down time).
perform: in percent, is the figure of merit that considers
the number of packets lost and the available time.
Gateway Availabilty
Note that the NRAC schools (NJIT, Stevens and UMDNJ) access to JVNC
was available 83% of the time, which is the lowest available time.
They were down 17% of the time due to line problems between JVNC
and NJIT. The Satellite schools (U. of Arizona, and U. of
Colorado) had access to JVNC 97% of the time. The 3% missing is
due to problems with the satellite dish. Following these schools
are the Cambridge/Rhode Island group (MIT, Harvard, Brown). They
Westine [Page 13]
Internet Monthly Report June 1987
were availabe 99% of the time, the remaining 1% unavailable time
was due to line problems.
All these percentages were taken when jvnca was up and available.
This happened 99% of the time.
Gateways
gateway school problems
------- ------ --------
egress NYU hardware problems
pusuper Princeton disk problems
iasvax IAS hardware problems
super-fs Rutgers disk problems
Besides these problems the gateways (all vax750's) manage to
pass packets most of the time.
Lines
from to type problem
----- -- ---- -------
JVNC COLUMBIA 56kbps NY Bell
JVNC MIT T1 Cambridge *
JVNC NJIT 56kbps NJ Bell
* trouble ticket still open
Satellite
Due to a severe power hit, we lost our Satellite Dish (hub of our
satellite network). It took Vitalink 1 day to bring it up back on
line. These affected the Universities of Arizona and Colorado.
Traffic
JVNCNET is configured like a star, and its traffic can be easily
computed at the center of the star. At the center of the star are
jvnca, jvncb, jvax, colo, fuzzball, terminal servers, and the front
ends to the super-computers.
Counting only the traffic received at jvnca, jvncb, routers and the
fuzzball, we received: 84,824,128 PACKETS... a very low estimate of
ONLY incoming packets, and it doesn't include all the gateways.
The data for the fuzzball was provided by Doug Elias (Cornell).
PSN
It is estimated to be connected to jvnca by the end of July.
Westine [Page 14]
Internet Monthly Report June 1987
Network Monitoring
Program still under development.
** for more information contact "heker@jvnca.csc.org"
By Sergio Heker (heker@jvnca.csc.org)
NATIONAL CENTER FOR ATMOSPHERIC RESEARCH AND UNIVERSITY SATELLITE
NETWORK PROJECT
The University of Miami is now isolated from the USAN 128.116
backbone. The Miami network (miami.edu) is 192.31.89. All host
table entries that were 128.116.10.x should now be 192.31.89.x. The
gateway machine is 128.116.10.1. Plans are under way to isolate
the remaining USAN node, Wisconsin.
Thanks to Mark Fedor, Cornell, gated appears to be operational on
windom.ucar.edu, NCAR's Sun3 OS 3.3. Inquiries about gated for OS
3.3 should be addressed to fedor@tcgould.tn.cornell.edu.
By Don Morris (morris@scdsw1.ucar.edu)
PITTSBURGH SUPERCOMPUTING CENTER
Both the PSC Fuzzball and PSC Gateway experienced only minor
downtime during June, nearly all of it scheduled. Early in the
month we reorganized part of our machine room to improve the
maintainability of these machines and other networking equipment.
PSC Gateway has continued to serve as the primary gateway for NSF
sites. We brought up the newest version of gated on June 25.
Our Fuzzball passed 14 million packets to the local net in June (up
from 11 million in May) making it again one of the busiest on the
backbone. We have been running the newest software version since
June 19.
Our Academic Affiliates net was born when gateways were installed
at Penn, Temple, and Lehigh early in the month. Later on, a T1
line to the University of Maryland was brought into service,
connecting a Proteon Gateway at the PSC to one of the SURAnet
Proteons. This line will allow higher bandwidth connectivity
between SURAnet sites and the PSC, and should soon serve as a
redundant path to the ARPAnet. The gated configurations were
updated on June 26 to reflect the existence of the line. During
June we also developed plans for a meeting of the Academic
Affiliates networking people to discuss the state of our network
and its future development.
By Dave O'Leary (oleary@morgul.psc.edu) PSC Communications
Westine [Page 15]
Internet Monthly Report June 1987
SAN DIEGO SUPERCOMPUTER CENTER
We have completed the cut-over of Software Tools mentioned last
month. It now supports mail to and from all our connected
networks.
A new version of the SRI Multinet has arrived and will be installed
during early July. This newest version will add support for GATED
and name server.
We have been working on our Cray FTP software. While it is still
in Beta, we have FTP'd files between our XMP and the one at NCSA
(UIll). Transfer rates of ~20k over the NSFnet 56k lines.
Our work with Apollo on Remote Procedure Call (RPC) service between
the Cray and our Apollo ring continues. We have implemented the
first simple step toward achieving a goal of distributing necessary
computations to the XMP while displaying the results on an Apollo.
We have sent two integers across the network to the Cray, which in
turn computed the sum and returned the value. Though this sounds
trivial, in is an important first step toward calling matrix
inversion routines, database information, and anything else where
resources, whether data or computational, on one machine are needed
by a process on another machine. Our goal is aimed at allowing
users to off load their computational needs to the Cray while using
specialized workstations to display the results.
None of the new lines mentioned last month has yet been installed -
several are "days away" but, of course, not yet carring any bits.
One addition to the list, we have been talking with JPL of leaving
our old 9.6 SPAN line installed but moving it over to connect one
of their Proteon's to ours. Hopefully by this time next month we
will have several new paths to the door.
By Paul Love (loveep@sds.sdsc.edu)
NSFNET REGIONAL AFFILIATED & CONSORTIUM NETWORKS
BARRNET
All sites are now in "production". All but two are running 7.3
release of Proteon software. Problems continue with sporadically
high error rates (at t-1 level) on dedicated microwave link,; to be
addressed by new equipment Current mix of vendors (Harris, ITE)
complicates problem resolution. Testing of the T-1 clear channel
links to the point where the telco can be convinced to allocate
resources or where link equipment fault can be isolated (in
microwave case) is essential to operation of BARRNET. Cost of
elementary (Bert) test equipment $6,000-7,000. We have had very
good luck to date with MCI supplied microwave link between Berkeley
and Davis, in contrast to some MCI experiences reported by other
Westine [Page 16]
Internet Monthly Report June 1987
regional nets. Because of vulnerability of end to end BARRNET
service to a single link failure, we are looking into establishing
a "back door" vax to vax route to Santa Cruz from Berkeley. Will
also examine NEC t 18 MHz digital microwave radio gear for
application to Stanford-NASA Ames link to reduce continuing telco
charges.
BARRNET is waiting for NSFNET backbone connection to San Diego to
be activated for connection to other than SDSCnet.
No representative was sent to Federation of Regional NETworks
meeting in Boston due to last minute problems; will definitely be
represented at next meeting.
Dave Wasley of UCB will coordinate technical discussion of NSFNET
backbone connection planning and connection preferences over next
month.
No response in writing has yet been received from Proteon on the
BARRNET recommendations (Wasley-BARRNET report - attached to this
status report for those interested). During recent visit of Howard
Salwen, they made oral commitments but said they were not in
agreement with some of the specific implementation details and
would respond.
-------------------------------------
Extracted From: "Modifications Required to Allow Proper Functioning
of the BARRNET Internetwork Routers"
May 18, 1987
Introduction
The Bay Area Regional Research Network (BARRNET) was one of the
first NSF sponsored regional networks to be proposed. In April of
1986, the BARRNET backbone network was scheduled to be in operation
by the end of March, 1987. Proteon was selected as the vendor for
the internetwork routers. Verilink T1 CSU's were selected with
Proteon's cooperation except for one link which is a private
microwave link (see separate report on CSU selection). Several
different T1 vendors were used for the 5 links based on lowest
cost. The equipment was delivered by the end of January, 1987, and
the first of the T1 circuits were turned over to BARRNET in
February.
Operation was delayed because of problems in developing a correct
configuration for version 7.2 of the Proteon p4200 internetwork
routers. The main problems encountered are summarized below along
with a specific request for a new feature in the p4200 software.
Westine [Page 17]
Internet Monthly Report June 1987
Implementation of this feature will allow BARRNET and the other NSF
regional networks to function reliably and correctly.
Installation History
The first obstacle encountered was during testing of the routers on
the T1 serial links and dummy local networks. The serial ports are
required to have IP addresses. Due to the way subnet code was put
into the p4200 software, if the router interconnects two networks
with different numbers, only one of them can be subnetted. This
meant that we could not use one of the campuses' registered class B
numbers for the serial links since it would have to interface with
another class B subnetted network on the other side of a router.
Since all BARRNET campuses are subnetted, each serial link must be
assigned a distinct non-subnetted network number.
Efforts to configure the links by using unregistered net numbers
and ensuring that they would not escape the BARRNET backbone proved
unsuccessful because the p4200 RIP code insists on advertising all
directly connected networks. Eventually the decision was made to
apply to the NIC for a range of class C network numbers for the
intercampus links a distinct number for each link. These have now
been assigned. This problem could have been avoided entirely if
the point-to-point links did not require IP network addresses, or
if there was more control over advertised routes.
A related but more significant obstacle was configuration of the
p4200s to meet the routing requirements defined by the BARRNET
technical committee:
1) BARRNET links should be used to support BARRNET traffic. In
other words, BARRNET traffic should not be routed outside BARRNET
unless the internal links are down.
2) BARRNET must provide a way to allow designated campuses to
act as ARPANET gateways for other campuses. In addition, multiple
paths to the ARPANET core from a given network number must not be
advertised to the core since this will break the existing core GGP
protocol.
3) There should be firewalls to ensure that bogus routing
information generated in one campus does not contaminate the
BARRNET backbone or the other BARRNET campuses. Furthermore, there
must be some mechanism for controlling which legitimate routes are
advertised to the other campuses.
4) Routing information should reflect currently available
links. If a link becomes unavailable, this information should
become known to the other routers and be reflected in the routing
information they propagate. In addition, if secondary, alternate
routes exist, they should be utilized.
Westine [Page 18]
Internet Monthly Report June 1987
Several approaches were attempted using both EGP and RIP. EGP was
considered because the routing-interchange parameter provides the
desired 'firewall' protection but had to be abandoned because it
could not be made to propagate derived routes. A way of enabling
this style of operation, either by setting the Autonomous System
parameter to 1, by setting all routers to the same Autonomous
System number, or by an explicit flag would have allowed BARRNET to
become operational. However, this would still rely on statically
defined routes in each router, so would fail requirement 4 above.
Running only RIP on all interfaces does provide complete route
information to each campus. If there was only one connection to
the ARPANET core, and no other external connections, this solution
would only suffer from exposure to bogus route information
potentially bringing down all of BARRNet.
Having exhausted all possible configurations of the existing
product without success, it was decided that Proteon must be asked
to modify in some way the p4200 software. After much discussion,
it was decided that the simplest satisfactory modification would be
a programmable route information filter. Because BARRNET
operation was already late, and because we wanted to verify that
this solution would be satisfactory, we decided to implement such
an algorithm in a microvax inserted between the p4200 routers and
the campus networks at several key BARRNET locations. This setup
is definitely a temporary kludge and is being implemented ONLY to
get BARRNET into operation as soon as possible. The configuration
parameters and interconnection are as follows:
1) Non-forwarding nodes - those with only one BARRNET router
and no other external connections - are configured to "send no
routes" on their BARRNET serial interface. Since this actually
means "send only a route to the directly attached network", this
provides a firewall of sorts. These routers also originate a
"default" route for their respective campuses.
2) The forwarding nodes, Berkeley and Stanford, are set to
"send net routes". This is necessary both for logical connectivity
of the two BARRNET routers at each of these sites, and for
advertising the availability of routes to the ARPANET core, etc.
3) To prevent the forwarding nodes from introducing unwanted
routes into the BARRNET route pool, a non-Proteon router will be
inserted between the p4200s and the rest of the forwarding nodes'
campus network. These routers will be programmed to implement the
route information filtering algorithm described below.
The fact that routers at different locations must be configured for
different types of RIP behavior (#1 & #2 above) is indicative of
the problems we faced in finding an adequate solution. Clearly, if
any of the member campuses changes its connectivity to the outside
Westine [Page 19]
Internet Monthly Report June 1987
world, the BARRNET routers will most likely have to be
reconfigured. This should not be the case.
It is essential to eliminate the need for the extraneous routers
(#3 above) as soon as possible. They are an extra cost to purchase
and maintain, and they introduce an extra router delay in the
topology. When the other campuses add further connectivity, they
too will need this same type of route filtering capability. It is
entirely unreasonable and unnecessary that these extra routers
should be required: the algorithm should be built into the Proteon
p4200 IP router software.
Below is an outline for a routing control feature which, if added
to the p4200 control software, would make the extra router
unnecessary. It would also allow uniform mode of operation in each
BARRNET router.
Proposed Route Information Control Feature
The purpose of the route information control feature is to provide
programmable filtering of route information within the internetwork
router. Both filtering of received ("learned") information and
explicit control over propagated information are provided. With
these two facilities, a reasonable firewall can be maintained
between adjacent network regions.
The following algorithm should be applied to any route information
received or propagated by the router. It is independent of any
particular route information protocol. RIP is used in the
discussion merely because that is what we're using currently.
For each interface, the p4200 should allow the construction of an
inclusion list and an exclusion list such that, on RIP input, for
any destination (route_dst) received, route_dst affects the p4200's
internal routing tables only if :
(no inclusion list was specified || route_dst is in the inclusion
list) && (no exclusion list was specified || route_dst is not in
the exclusion list )
It is an error, although benign, for there to be both an inclusion
list and an exclusion list for the same interface.
A similar facility would control RIP output. In this case the
above test would be applied to each route_dst in the p4200's
internal table and the destination would appear in the p4200's RIP
broadcast on that interface only if the condition evaluated to
true. The output filter list is distinct from the input filter
list for each interface.
Note that knowledge of routes to directly connected networks are
Westine [Page 20]
Internet Monthly Report June 1987
not affected by the input filter, but that advertising those routes
IS affected by the output filter. Learning or advertising of a
default route is also affected by this algorithm.
A plausible command syntax to allow specification of this facility
might be:
add route_input_filter {include|exclude} <net_number>
<interface>
add route_output_filter {include|exclude} <net_number>
<interface>
delete route_input_filter {include|exclude} <net_number>
<interface>
delete route_output_filter {include|exclude} <net_number>
<interface>
where the 3rd & 4th arguments are a pair in which the first token
is "exclude" for exclusion or "include" for inclusion and the
second item is the destination network or subnetwork number. For
example, the commands:
add route_output_filter include 128.32.0.0 3
add route_output_filter include 0.0.0.0 3
would ensure that RIP packets emitted on interface 3 would contain
no more than a default route and a route to network 128.32.0.0.
The command:
add route_input_filter exclude 0.0.0.0 1
would ensure that a default destination received on interface 1
would be ignored.
It is assumed that the basic rule: "routes learned via interface N
are not advertised on the same interface N" still applies. Proteon
should verify this.
Possible Extensions
There are several obvious extensions possible, building on the
basic syntax described above. These extensions are NOT required
for BARRNET and are mentioned merely in case they are interesting
to Proteon.
One extension could supplant the existing "send [sub]net routes"
command. The command could be something like:
add route_output_filter include {sub|}net_routes <interface>
A further extension would interpret a 6th argument as a value to be
added to the RIP metric when manipulating the route. Thus a route
Westine [Page 21]
Internet Monthly Report June 1987
could be made to appear arbitrarily distant. This would be used to
define secondary routes.
Yet another extension would be to apply similar filtering to the
source of the route information packets. This would be used to
guard against trusting normal looking information about legitimate
routes originating from "untrustworthy" network nodes.
Conclusion
The basic function of the Proteon p4200 as an internetwork router
works well. The only serious problem with their use as routers in
a regional network is the lack of a programmable firewall for
routing information. The algorithm described above would provide
that control feature.
Comments solicited.
Bill Yundt GD.WHY@forsythe.stanford.edu
JVNCNET (Refer to JVNNSC backbone report)
MERIT
At the Merit/UMNET site, work continued this month on the network-
side TCP/UDP module. The TCP/IP driver for the Interlan board is
now working, allowing our Primary Communications Processors to join
our Secondaries in supporting TCP/IP over Ethernet. Members of our
staff adapted Phil Karn's TCP/IP package to work with the MIT
Serial Line Protocol so that it can be used in the Merit
environment. The central-site Technical Support Group taught a
six-hour lecture course on computer networking technology on the UM
campus, with heavy emphasis on the TCP/IP suite of protocols.
Merit member Michigan State University was officially assigned the
domain name MSU.EDU this month and has brought up a domain server
to service MSU.EDU and its subdomains. At this point MSU has
fourteen buildings connected to the campus-wide Ethernet; those
locations house fifteen departments and over 200 nodes running
DECNET, TCP/IP, and/or XNS. MSU is working on getting all of the
systems on campus upgraded to compatibility with 4.3 bsd Unix.
At Western Michigan University, TCP/IP systems on the campus are
now able to reach all Merit-connected IP hosts. Work is
progressing on getting such connections passed through to the rest
of the Internet. WMU is on the verge of releasing TCP/IP to all
its users and is preparing to apply to the NIC for a domain name.
In the middle of the month the Merit Board of Directors authorized
Merit's director to upgrade the remaining links between member
universities to 56 Kbps. This will in effect bring nearly all of
Westine [Page 22]
Internet Monthly Report June 1987
our statewide backbone up to that speed.
By Christine Wendt (christine_wendt@um.cc.umich.edu)
MIDNET
The MIDNET Consortium met at the University of Nebraska-Lincoln on
June 22, 23, and 24. The meeting had two tracks: technical and
general. The technical track was attended by the campus technical
representitives and covered the care and feeding of the
gateway/routers. The entire network was assembled and running in
the training room. One of the most useful results of running the
training this way was that the participants got some practical
experience in what to do when things go wrong. In addition to
vendor documentation, the participants were provided with an
extensive "startup" manual prepared by Mark Meyer. A video tape of
these sessions will be made available shortly.
The general session covered administrative issues such as how to
deal with potential corporate members and state networks, reviews
of what is going on nationally in networking, the status of the
various supercomputer centers, a tutorial on internet concepts,
user service issues related to supporting campus supercomputer
users, and a technical review of ways to connect TCP/IP networks to
vendor secific campus networks. Participants left the general
session with several inches of documentation on these subjects.
Anyone interested in obtaining any of these documents should
contact either me (DOUG@UNLCDC3 on bitnet) or Mark Meyer
(MARK@UNLCDC3 on bitnet).
All of the telephone lines are scheduled to be in within a few
weeks. At that time we will bring the entire network up in a
systematic way. We hope to be fully operational with all nodes
available by August 1.
By Doug Gale (doug%unlcdc3.bitnet@WISCVM.WISC.EDU)
NORTHWESTNET
We have just received word that the grant instrument has been
signed by NSF. We will provide further detail next month.
By Hellmut Golde (golde@june.cs.washington.edu)
NYSERNET
As of 1 July 1987, NYSERNET has the following topology with 56kbit
links and Proteon Gateways. Reachability to NSFNET, ARPANET,
MILNET, etc is available to each site. June additions include SUNY
StonyBrook, City University of New York (CUNY), Polytechnic
University (PU), and Rockefeller University.
Westine [Page 23]
Internet Monthly Report June 1987
Clarkson
Syracuse--+ |
| |
Rochester--------Cornell---------RPI---Albany
| | |
Buffalo | |
| | |
Binghamton | +-------- | ------StonyBrook
| | | |
CUNY------NYTEL----Columbia------NYU
|\ | | /|
| \ | NYNEX / |
| \ BNL / |
| \ / |
| +--------------Rockefeller|
| |
POLY------------------------------+
A draft version of a Simple Gateway Monitoring Protocol (SGMP) was
released for comment to the INTERNET community. This was a joint
effort of some regional participants and Proteon. It is hoped that
deployment in NYSERNET will begin in August or September with a
number of campus networks also participating. The p4200/GATED
versions and a UNIX/MSDOS NOC portion are the short term
objectives.
A two day meeting was held at Cornell University on June 22nd and
23rd, to explore and discuss ways in which libraries can utilize
the regional and national tcp/ip networks. 45 people, including
representatives from the Library of Congress, RLG (The Research
Libraries Group), OCLC (The Online Computer Library Center), and
NYSERNET member libraries met to discuss both the technical
feasibility and the desirability of a collaborative relationship.
Small working groups, consisting of technical and library
personnel, were asked to consider three basic proposals. These
three proposals focused on: the availability of national
bibliographic utilities on NYSERNET, more efficient document
transmission for the purpose of interlibrary loan and, the
availability of regional and special interest databases through
NYSERNET. The groups proposed many methods for the immediate
implementation of these proposals, each demonstrating the benefits
of a joint effort among libraries and NYSERNET.
A steering committee will follow through to determine the steps
required for implementation of these proposals to the fullest
extent possible.
By Marty Schoffstall (schoff@nic.nyser.net)
Westine [Page 24]
Internet Monthly Report June 1987
SDSCNET
(Refer to SDSC backbone report)
SESQUINET
As of July 2nd, we are up with gateways at three campuses:
Baylor College of Medicine,
Houston Area Research Center, and
Rice University.
At each campus is a cisco gateway, with an additional internal
router in downtown Houston. All links are via 56 kb/s DDS
circuits, with the exception of one 448 kb/s link between downtown
Houston and HARC.
The initial Rice-to-BCM link reported up a month ago served a light
load, but with only one interruption (due to an inadvertant pulling
of a power plug).
During the month of July, we plan to install connections to three
additional campuses:
Texas A&M University,
Texas Southern University,
and the University of Houston.
A technical report describing the network in more detail was
written during June and is available to anyone asking me for it.
By Guy Almes (almes@rice.edu)
SURANET
The following nets are being EGP advertised to the core on
SURANET's behalf.
Westine [Page 25]
Internet Monthly Report June 1987
128.61. Georgia Tech
128.109. TUCC
128.150. NSF
128.154. NASA Goddard
128.163. U of Kentucky
128.164. George Washington Univ
128.167. SURAnet
128.169. U of Tennessee
128.173. Virginia Tech
192.5.57. Univ of Delaware (udel-cc)
192.5.219. Clemson
192.16.177. Univ of Alabama
The T1 line between SURANET and the Pittsburgh Supercomputing
Center was installed in June. After some initial problems with the
Clear Channel CSU the connection appears to be working properly.
The 56kb phone line to Florida State University is installed and
has been working. The Florida State University network (128.186)
will be EGP advertised to the core within several days.
Telecommunication vendors for the Phase II SURANET sites were
selected. Lines have been ordered for these sites and present plans
are for all of the lines to be installed by the first of September.
Discussions are continuing with several Federal Research
Laboratories about establishing connections to SURANET.
By Jack Hahn (hahn%umdc.bitnet@wiscvm.wisc.edu)
WESTNET
Connection to NSFNET - Ed Krol arranged for the connection to
NSFNET through NCAR. Don Morris of NCAR is working with Hans
Werner-Braun to update the routing tables. This will give us the
much needed capability to Telnet to Phase II Centers in addition to
JVNC, where we previously had access. Thank you to all parties
involved.
Gateway Proposals - Vendor responses to our RFP for IP Gateways are
due to be received by July 8, 1987. We anticipate having made a
selection by July 15, 1987. We will include the details of the
evaluation results in next month's progress report.
Interaction with AT&T - We have prepared a draft of a letter to the
Denver Office of AT&T to request cost sharing for circuit costs in
the interim until full NSF funding becomes available. This draft
letter is presently undergoing internal CSU review. If any of you
have such letters, or have contacted your local AT&T office, I
would greatly appreciate it if you would share your letters and/or
experiences with me. Send information to: pburns@csugreen.bitNET
Westine [Page 26]
Internet Monthly Report June 1987
We as yet have no NSF funding, although it is imminent, according
to Dave Staudt at NSF.
An overview presentation of Campus Networks, Regional Networks, the
NSFNET Backbone and the Internet is being prepared for delivery at
our "NSF Summer Institute on Vector Supercomputing" to be held from
July 13 to July 24. At this time, we plan to provide information on
national NETworking and to allow the participants to exercise the
networks by running examples on extramural systems.
By Pat Burns (pburns%CSUGREEN.BITNET)
TASK FORCE REPORTS
------------------
APPLICATIONS -- USER INTERFACE
No report received.
AUTONOMOUS NETWORKS
Nothing to report this month.
Deborah Estrin (Estrin@oberon.usc.edu)
END-TO-END SERVICES
VMTP
Dave Cheriton reports progress on VMTP at Stanford: further
extensions to the UNIX kernel implementation of VMTP, to
include security in an initial form and some performance
tuning; some work on modifying the VMTP packet format for ease
of hardware implementation and improved error checking; and
additional work on the RPC interface to VMTP and preliminary
examination of presentation levels such as XDR relative to
VMTP. A new release of the VMTP Unix software is available
and Steve Deering is now taking charge of incorporating bug
fixes from CMU.
Eric Cooper's MACH networking group at CMU has brought up the
UNIX VMTP code and is thinking about how to use it in MACH.
The semantic differences between MACH IPC and VMTP are
significant enough to pose some non-trivial problems.
Westine [Page 27]
Internet Monthly Report June 1987
MULTICASTING
The MACH networking group has installed the Deering/Lam IP
Multicast code in the MACH kernel and has started
experimenting with it. Two groups will be using it in the near
future: one working on multi-RPC for a replicated file system,
and another doing commit protocols for distributed atomic
transactions.
ISO TRANSPORT PROTOCOLS
UCL has been doing some preliminary thinking on the problems
of interworking between the two predominant OSI architectures,
namely TP class 4 over connectionless ("ISO-IP"), and TP class
0 over X.25. The obvious solution is an application-level
relay, but they are more concerned with developing a method
for dealing with the addressing and flow control issues (with
associated "layer violation") of concatenating these two types
of service. Their X.25 systems would allow them to build a
transport level relay that had access to X.25 flow control
information on both the read and write sides, and passed this
up to the TP4 on the other side of such a relay.
PERFORMANCE
UCL has been doing follow-up work to Peter Lloyd's
measurements of IP and TCP performance. They have been
collecting, modifying and writing tools for this purpose, and
have an icmp and tcp traffic generator, together with a tool
for monitoring TCP's internal and externally-visible
behaviour. Current plans are to carry out a set of tests over
the SATNET path, and concatenated SATNET and ARPANET paths.
Preliminary measurements show that even the latest versions of
TCP have problems coping with high variance of delay (2.5 secs
+10 secs or -.5 secs) coupled with significant packet loss
(>5%). This work is being carried out in collaboration with
BBN and NTA.
Phil Karn and Craig Partridge have written a paper on
"Estimating Round-Trip Times in Reliable Transport Protocols",
which is going to be presented at SIGCOMM in August. It's an
update to Lixia's paper and analyzes ways to get around the
problems she identified in the TCP algorithms.
Van Jacobson reports on his efforts towards modelling and
improvement of Internet performance. This information is of
sufficient interest to this community to warrant its verbatim
inclusion:
"... Mostly I've been working on a paper about rtt modelling
and the use of such models in transport protocols. The paper
Westine [Page 28]
Internet Monthly Report June 1987
is about 30 pages currently and maybe 1/3 finished. I was
hoping to distribute a finished draft at the upcoming end2end
and ietf meetings. It doesn't look like that's in the cards
(I hate to write so it's going slowly). If there's interest,
I could distribute a draft of the incomplete paper in the hope
of getting some feedback at or before the meetings.
Other things that have happened are:
-- Mike Karels and I finished putting the slow-start
algorithm into the official 4.3bsd system at Berkeley.
Preliminary analysis of tcp statistics we are now
routinely gathering on ucbvax shows approximately the
same behavior as earlier measurements on lbl-rtsg: Under
congested, mid-day conditions, ARPANET throughput showed
a moderate improvement (20-50% better than no slow-start)
and retransmitted packets showed a large improvement
(factor of 4-6 fewer with slow-start).
-- I've collected the notes for a slow-start rfc but, never
having written an rfc, don't know what to do next. I
want to get the rfc written to at least correct the
attribution of the algorithm: Several people have said
"Jacobson's slow-start" but it's not. John Nagle, Mike
Karels and I independently described the algorithm at
about the same time (round about the new year). John
Nagle coined the name "slow start". I called it "soft
start" (thinking of the soft-start inductors we have to
use when turning on our high-voltage power supplies).
Karels called it "a new timeout algorithm".
Had I been up to date in my journal reading, I would have
noticed an excellent article by Raj Jain in the October,
86, IEEE Journal on Selected Areas in Communications ("A
Timeout-Based Congestion Control Scheme for Window Flow-
Controlled Networks"). The article describes something
very close to the slow-start algorithm we put into 4.3bsd
tcp (Jain used the acronym CUTE for the algorithm, a name
that's a bit too cute for me). Unfortunately, I'm a year
behind on journals and read Jain's article about a month
after implementing the tcp slow-start. But he published
the algorithm long before I thought or heard of it.
-- We have been trying a small variation of the RFC-793
timer algorithm that estimates both mean and variation
(i.e., "beta" is replaced by a dynamic estimate). The
variance computation is substantially faster than the one
proposed by Stephen Edge and, surprisingly, the cost of
estimating both rtt mean and variance by the new
algorithm is less than the cost of estimating just mean
Westine [Page 29]
Internet Monthly Report June 1987
in 4.3bsd. We tested the algorithm for two months on a
couple of LBL machines and found it improved performance
on all types of links: Retransmits came sooner on local-
net and low variance, long haul links and there were
fewer spurious retransmits on high variance Arpanet and
Milnet links. Based on this success, we have put the
algorithm into the production 4.3tcp at Berkeley and hope
to soon have data from ucbvax quantifying the
improvement.
I sent a short note to the tcp-ip list describing the new
algorithm (in response to a query from Mark Lambert of
MIT). I should probably turn that note into a short rfc.
(That last sentence is actually a question.)
-- With help from Bill Nowicki of Sun and Mike Karels of
Berkeley, we moved the current 4.3bsd tcp code to some
Sun workstations. We then compared local net performance
of the original Sun code (essentially 4.2bsd tcp) with
4.3's. Ftp transfer rates between two Sun 3/50's
improved a factor of two (100Kbyte/sec to 195Kbyte/sec).
When measuring task-to-task tcp throughput (since ftp
measurements are contaminated by file system overhead),
we observed an interesting "silly window" phenomenon that
could only occur at very high throughputs (i.e., when the
average task-to-kernel time was approximately equal to
the kernel-to-wire time). After putting a fix for this
phenomenon into the 4.3 tcp, task-to-task data throughput
between two Sun 3/50's climbed from 335 Kbytes/sec to
390Kbytes/sec (the 4.2 tcp code could only achieve 230
Kbytes/sec).
We were pleased with this performance from a stock,
4.3bsd tcp (it corresponds to 3.3Mbps on the wire or 1/3
of the ethernet bandwidth) and hope that the people that
have been saying "the tcp protocol is inherently slow"
will now shut up. If necessary, kernel profiling has
shown there's another factor of two to be gained but we
have begun to worry that our ethernet will become
unstable if pairs of workstations routinely use 60-70% of
the available bandwidth (this will also be a problem if
Sun ever puts a decent ethernet interface on the 25MHz
3/2xx series).
-- We want to test several 4.3bsd tcp changes aimed at
improving performance under high packet loss (the recent
changes have been aimed at improving performance under
congestion). One goal would be to get near-bandwidth
performance from tcp across a high-delay, high-bandwidth
satellite link. Mike Karels has made the first kernel
Westine [Page 30]
Internet Monthly Report June 1987
changes (of a set of several) that should allow us to
expand the tcp window size beyond 64KB (oops, I'll
probably need to write an rfc for a new "large window"
tcp option. Looks like I'm signing up for too much
writing & not enough fun stuff).
I've sketched out an algorithm that should detect packet
loss in much less than two round-trip-times. The
algorithm includes an estimator that detects that packets
are seldom reordered or duplicated on this path, then a
threshhold detector that judges whether duplicate acks
indicate dropped packet(s). The algorithm will always
retransmit in about one rtt. Its big advantage is it
doesn't require a high resolution clock for good
performance. With this and Selective Acknowledgments, we
should have all the pieces we need.
-- I also finally realized that tcp round trip timing is
trivial if you have the equivalent of an ICMP echo at the
transport level. I.e., if the sender can put a timestamp
(or other, arbitrary data) in the tcp header which the
receiver just reflects back. This removes all the
ambiguity on rtt after retransmission and saves the
sender from a lot of timer processing. I sketched out
how the sender would work if this option existed, then
used that sketch to spec receiver behavior. I think I
have an algorithm that will work well, removes a lot of
code from the sender and adds just a bit of code to a
receiver. But testing will probably require another tcp
initial option for the receiver to announce it has the
"reflect" capability (another rfc?).
That's all I can think of. It's been a slow month (but
exciting - my car caught fire and burned up while I was
standing next to it, pumping gas). Cheers. - Van
Bob Braden
INTERNET ARCHITECTURE
The INARC list was quiet this month. Several issues of
importance, including routing and congestion-control issues,
were discussed on other lists. Meeting plans will be
announced shortly after the next IAB meeting in early July.
Dave Mills
Westine [Page 31]
Internet Monthly Report June 1987
INTERNET ENGINEERING
Task Force activity has slowed during the month of June.
There will be a meeting in July during which several working
groups will meet.
Phil Gross
INTERNET MANAGEMENT
No meetings held in June. Cerf is late in distributing the
synthesized summary of the 3 day effort in May.
Vint Cerf
PRIVACY
Minutes of the March-April Privacy Task Force meeting were
distributed to the membership. John Linn provided
explanations and clarifications to several parties engaged in
implementation of privacy-enhanced mail mechanisms per RFC989.
Our next meeting is set for 28-29 July at NBS. The second day
of this meeting will be held as a joint session with an ISO
working group which is examining approaches to electronic mail
privacy and security.
John Linn
ROBUSTNESS AND SURVIVABILITY
No progress to report.
Jim Mathis
SCIENTIFIC COMPUTING
No report received.
Westine [Page 32]
Internet Monthly Report June 1987
SECURITY
No report received.
TACTICAL INTERNET
No report received.
TESTING AND EVALUATION
No report received.
Westine [Page 33]