/share/doc/smm/18.net/e.t

  1.\" Copyright (c) 1983, 1986, 1993
  2.\"	The Regents of the University of California.  All rights reserved.
  3.\"
  4.\" Redistribution and use in source and binary forms, with or without
  5.\" modification, are permitted provided that the following conditions
  6.\" are met:
  7.\" 1. Redistributions of source code must retain the above copyright
  8.\"    notice, this list of conditions and the following disclaimer.
  9.\" 2. Redistributions in binary form must reproduce the above copyright
 10.\"    notice, this list of conditions and the following disclaimer in the
 11.\"    documentation and/or other materials provided with the distribution.
 12.\" 3. All advertising materials mentioning features or use of this software
 13.\"    must display the following acknowledgement:
 14.\"	This product includes software developed by the University of
 15.\"	California, Berkeley and its contributors.
 16.\" 4. Neither the name of the University nor the names of its contributors
 17.\"    may be used to endorse or promote products derived from this software
 18.\"    without specific prior written permission.
 19.\"
 20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 23.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 30.\" SUCH DAMAGE.
 31.\"
 32.\"	@(#)e.t	8.1 (Berkeley) 6/8/93
 33.\"
 34.nr H2 1
 35.\".ds RH "Trailer protocols
 36.br
 37.ne 2i
 38.NH
 39\s+2Trailer protocols\s0
 40.PP
 41Core to core copies can be expensive.
 42Consequently, a great deal of effort was spent
 43in minimizing such operations.  The VAX architecture
 44provides virtual memory hardware organized in
 45page units.  To cut down on copy operations, data
 46is kept in page-sized units on page-aligned
 47boundaries whenever possible.  This allows data
 48to be moved in memory simply by remapping the page
 49instead of copying.  The mbuf and network
 50interface routines perform page table manipulations
 51where needed, hiding the complexities of the VAX
 52virtual memory hardware from higher level code. 
 53.PP
 54Data enters the system in two ways: from the user,
 55or from the network (hardware interface).  When data
 56is copied from the user's address space
 57into the system it is deposited in pages (if sufficient
 58data is present).
 59This encourages the user to transmit information in
 60messages which are a multiple of the system page size.
 61.PP
 62Unfortunately, performing a similar operation when taking
 63data from the network is very difficult.
 64Consider the format of an incoming packet.  A packet
 65usually contains a local network header followed by
 66one or more headers used by the high level protocols. 
 67Finally, the data, if any, follows these headers.  Since
 68the header information may be variable length, DMA'ing the eventual
 69data for the user into a page aligned area of
 70memory is impossible without
 71\fIa priori\fP knowledge of the format (e.g., by supporting
 72only a single protocol header format).
 73.PP
 74To allow variable length header information to
 75be present and still ensure page alignment of data,
 76a special local network encapsulation may be used.
 77This encapsulation, termed a \fItrailer protocol\fP [Leffler84],
 78places the variable length header information after
 79the data.  A fixed size local network
 80header is then prepended to the resultant packet. 
 81The local network header contains the size of the
 82data portion (in units of 512 bytes), and a new \fItrailer protocol
 83header\fP, inserted before the variable length
 84information, contains the size of the variable length
 85header information.  The following trailer
 86protocol header is used to store information
 87regarding the variable length protocol header:
 88.DS
 89._f
 90struct {
 91	short	protocol;	/* original protocol no. */
 92	short	length;	/* length of trailer */
 93};
 94.DE
 95.PP
 96The processing of the trailer protocol is very
 97simple.  On output, the local network header indicates that
 98a trailer encapsulation is being used.
 99The header also includes an indication
100of the number of data pages present before the trailer
101protocol header.  The trailer protocol header is
102initialized to contain the actual protocol identifier and the
103variable length header size, and is appended to the data
104along with the variable length header information.
105.PP
106On input, the interface routines identify the
107trailer encapsulation
108by the protocol type stored in the local network header,
109then calculate the number of
110pages of data to find the beginning of the trailer. 
111The trailing information is copied into a separate
112mbuf and linked to the front of the resultant packet.
113.PP
114Clearly, trailer protocols require cooperation between
115source and destination.  In addition, they are normally
116cost effective only when sizable packets are used.  The
117current scheme works because the local network encapsulation
118header is a fixed size, allowing DMA operations
119to be performed at a known offset from the first data page
120being received.  Should the local network header be
121variable length this scheme fails. 
122.PP
123Statistics collected indicate that as much as 200Kb/s
124can be gained by using a trailer protocol with
1251Kbyte packets.  The average size of the variable
126length header was 40 bytes (the size of a
127minimal TCP/IP packet header).  If hardware
128supports larger sized packets, even greater gains
129may be realized.