Experiences with a Production Gigabit LAN
USC/ISI Computer Networks Division
April 1997
As appearing at the GBN '97 Meeting, Kobe, Japan
This work is supported by the Advanced Research Projects Agency
through Ft. Huachuca contract #DABT63-93-C-0062 entitled ``Netstation
Architecture and Advanced Atomic Network''. The views and conclusions
contained in this document are those of the authors and should not be
interpreted as representing the official policies, either expressed or
implied, of the Department of the Army, the Advanced Research Projects
Agency, or the U.S. Government. We receive additional support from
Calren's ARC Consortia and GTE's SCAN Project.
ISI Installation Layout
Production LAN
- Problem:
- Need to test scale and in situ properties
- User wants service that tracks R&D
- User needs reliability, autonomy - use backup routes
- Dual-homed hosts are atypical
- Typical LAN solutions fail
- Solution:
- Use hosts as routers
- DNS interface names
Backup network routing
Lab vs. LAN
Lab installation
8-port switch
Sun SPARC host interface
LAN installation
8-port switch installed in a ceiling
Sun SPARC host-based gateway to ATM and Fast-ethernet
gateway cables entering ceiling
Cable coming from wall (no connector plate possible)
Cable coiled on office floor (no length adjustments)
Fast-reset TCP
- Problem:
- TCBs buildup on server
- Caused by server-side active close
- Results in slower server TCP processing
- Solution:
- Client assumes TCB vigil
- RST sent on LAST_ACK � TIME_WAIT (recv. ack)
- Client stays in TIME_WAIT, keeps TCB
- Server goes to CLOSED, releases TCB
Networked File Systems
- Problem
- Disks are slow
- RAID requires large files
- NFS is slow
- XDR is slow
- Solutions
- RAM disk for high BW, small files
- Fast-path pipelined NFS, aggregate processing
- Avoid unneeded copies in XDR
- Off-load protocol onto disk CPU
- But...still stuck with shared bus limit
NFS vs. Modified (optimized) NFS, vs. TCP to RAM disk performance
Security
- Problem:
- Stand-alone code is provably slow
- In situ is worse - No send ILP
- Solution:
- Design fast, (weaker) hash algorithms
- Parallelizable, hardware-efficient
- Native big- and little-endian
- Measure component overheads
- Steep in situ penalty
- Nearly constant, but lower data touching overheads
AH over TCP requires two passes, hindering ILP
Summary
http://www.isi.edu/atomic2/
- Conclusions
- I/O busses are a big problem
- Interface DMA peering is critical (both gateway and disk)
- LAN version of backbone tools would help
- Large-scale testing exposes new effects
- Key Results
- Large fault-tolerant gigabit LAN in production use
- Minor TCP mod. helps close-initiating servers scale
- Fast-path NFS works
- Viable host gateway, but needs DMA peering
- Some AH algs are provably slow; in situ penalty is steep
Go to the ATOMIC-2 Project home page. / Go back to the ISI home page. 
This page written and maintained by the
ATOMIC-2 group.
Please mail us any problems with or
comments about this page.
Last modified: Thu Apr 3 09:37:36 1997
ATOMIC-2