1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
|
<pre>Network Working Group A. Bhushan, MIT
Request for Comments #176 R. Kanodia, MIT
NIC #7100 R. Metcalfe, MIT
Categories: C and D J. Postel, UCLA
14 June 1971
<span class="h1">Comments on Byte Size for Connections</span>
<span class="h1">-------------------------------------</span>
There are at least the following three views on the use of
byte size for network connections*:
1) Byte size should not be used at all.
2) Byte size is solely for the convenience of NCP's.
3) Byte size choice is a user-level prerogative.
According to the first view, network connections are bit
streams, and messages should contain bit counts (i.e., a
byte size of 1). This view existed before the "Glitch Cleaning"
of <a href="./rfc107">RFC 107</a>, and was discarded in favour of byte stream because
of stated reasons of efficiency in storage management and
message concatenation.
The second view represents a special interpretation of
<a href="./rfc107">RFC 107</a>. According to this interpretation, byte size is
entirely a 2nd level (i.e., NCP) issue. There is no require-
ment that 3rd level user processes be able to specify byte size.
This view is indicated in <a href="./rfc151">RFC 151</a> by Shoshani.
----------------------
* Byte size for connection is the byte size selected by
sending NCP, as explained in <a href="./rfc107">RFC 107</a> (Output of Host-Host
Protocol Glitch Cleaning Committee).
<span class="grey"> [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey">RFC #176 -2- NIC #7100</span>
According to the third view user processes are always
allowed to choose byte size for connection, either explicitly
(specify a specific byte size parameter) or implicitly (byte
size depends on I/O mode). An NCP is allowed to use a default
byte size, if the user does not specify it.
The Correct View
________________
The third view should be considered the correct interpre-
tation of <a href="./rfc107">RFC 107</a>. In fact, <a href="./rfc107">RFC 107</a> states on page 2, "the
choice of the byte size for a connection is a 3rd level protocol
issue." To be consistent with TELNET, ICP, and other 3rd
level protocols which require that a specific byte size be
used for connection, it is imperative that corresponding 3rd
level processes be able to specify (and_impose) a particular
byte size to the NCP. NCP implementors should take note of it.
On Specifying Fixed Byte Sizes in 3rd Level Protocols
-----------------------------------------------------
Holding the view that byte size choice is a 3rd level
issue, we are still faced with the following two questions.
First, is it appropriate for 3rd level protocols to legislate
a specific byte size for all connections using that protocol?
Second, if it is appropriate to specify byte size, then what
should this choice be?
<span class="grey"> [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey">RFC #176 -3- NIC #7100</span>
There are two arguments in favour of using specific
byte size in 3rd level protocols. First is that a potential
mismatch problem exists because <a href="./rfc107">RFC 107</a> does not require
that NCPs be capable of handling all byte sizes 1 through 255.
Using a fixed byte size of 8-bits or 8-bit multiples resolves
the problem as this is acceptable to all hosts (including
terminal IMPs).
The second argument is one of efficiency. If it is agreed
before hand that only a specific byte size would be used,
it is possible to make programs more efficient (i.e., reduce
program space, and possibly run time). The efficiency argument
assumes that the byte size for connection represents the natural
byte structure of data being transferred over the connection.
For TELNET and ICP, the byte size choice is straight
forward as data is naturally in 8-bit multiples (8-bit ASCII
characters in TELNET, and 32-bit socket numbers in ICP). But
for data transfer protocols, the byte size choice is more complex,
as data may be structured in a variety of byte sizes. Specifying
a byte size for a data transfer connection reduces efficiency
in instances where connection byte size does not correspond
to data byte size. Further, filler fields will be required
for data blocks which are not a multiple of the fixed byte
size. This imposes an additional overhead.
<span class="grey"> [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey">RFC #176 -4- NIC #7100</span>
Even if all hosts were to accept arbitrary byte sizes,
and the 3rd level protocol does not legislate a specific byte
size, the inefficiency problem will not be solved entirely.
Under current specifications "the byte size is fixed for the
life of a connection".* This means that byte size cannot be
varied during the life of a connection even if structure of
data varies. The problem of inefficiency is solved only for
instances in which data has a constant byte structure.
Given the current state of the network, it appears that
specifying fixed byte size in 3rd level protocols is a good
idea. This eliminates the potential byte size mismatch problem,
and improves efficiency at least for TELNET and ICP. In data
transfer, the efficiency issue is more complex, as discussed
earlier. It is not clear that overall efficiency would be
degraded if a fixed byte size was required.
On Reopening the Byte Size Issue
--------------------------------
The above discussion exposes certain weaknesses in the
efficiency arguments for having byte streams on network connec-
tions. In moving from bit stream to byte stream, we may have
lost generality, and it is not clear how much overall efficiency
is gained. Sometimes, the gain in NCP efficiency may be at the
expense of user process efficiencies.
--------------------
* <a href="./rfc107">RFC 107</a>, page 2
<span class="grey"> [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey">RFC #176 -5- NIC #7100</span>
It is also clear that for efficiency arguments to hold,
the byte size choice should not be an NCP prerogative. It
is the combined efficiency, rather than NCP efficiency which
should be our primary concern. Restricting byte size choice
to NCPs has the further disadvantage of potential byte size
mismatch not only between communicating NPCs but also at the
user-NCP interface. Therefore, allowing a user process to
specify byte size is a step in the right direction, given
that we have adopted byte streams.
It is our opinion that the issue of bit stream and byte
stream be set aside until serious consideration can be given
to a major Host-Host Protocol overhaul. At a later stage
we will have a better idea of the relative efficiency merits.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 12/96 ]
[Page 5]
</pre>
|
