Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/ien/ien51.txt Дата изменения: Mon Jun 25 22:44:51 2001 Дата индексирования: Tue Oct 2 09:14:42 2012 Кодировка:






INDRA Note 680
IEN 51
21st July 1978










Types of Service in the Catenet

C. J. Bennett










ABSTRACT: The three main traffic types each require
different types of service support in the catenet.
The impact of offering support for particular
services on the catenet architecture is discussed.
The major problem identified is supporting bulk
transfer, due to the lack of gateway to gateway flow
control.










INDRA Research Group
Dept of Statistics and Computer Science
University College London

1



Introduction

The last internet meeting raised the question of how the internet
datagram protocol can support various kinds of service. At that
meeting, the three standard traffic types were identified as defining
the types of service we wished to support by their characteristics. The
aim of this note is to identify in more detail services needed to
support these traffic types, and to point out the areas of the internet
and gateway protocols which will be affected by the need to support
them.

Interactive Traffic.

Interactive traffic is characterised by short packets sent at
irregular intervals, and requiring a response within a time determined
by a user's tolerance threshold - typically, a second or so. Hence the
prime constraint that must be satisfied for an interactive service is
simply that the packets be delivered with the minimum delay.

The internet protocol as it currently stands does not guarantee
delivery (Postel78), and the proposed form of gateway congestion control
is simply gateway blocking (Cerf77). Hence, flow control is maintained
by the routing algorithm. Thus supporting a minimum delay requirement
means in operational terms that the traffic should be routed along
minimal delay paths. This can be done by requiring the gateways to use
minimum delay as the objective function of the routing algorithm. This
is in fact the basis of the dynamic routing scheme suggested in
(Strazisar78), and so support of low-delay traffic simply requires the
catenet to operate in its normal mode, once this dynamic routing is
installed.

On the other hand, the catenet cannot offer classes of minimal
delay service on this basis. This needs minimisation of queueing delays
rather than tranmission delays, which makes its operation very similar
to priority classes. As we shall see in the next section, priority
classes also play an important role in supporting stream traffic.

Stream Traffic

The second traffic type requiring service support is stream
traffic. Typically, this will consist of a steady flow of data such as
voice or telemetry data. The data will usually contain a high degree of
redundancy, and so a degree of packet loss is tolerable. However,
significant congestion leading to the loss of a large contiguous section
of the data should be avoided. Often the traffic source will be of low
intelligence, so techniques for retaining end-to-end reliability may not
be possible in any case. Different applications of stream traffic will
have different requirements on the catenet. Traffic voice, for
instance, has a strong requirement for minimising end-to-end delay,
though the main requirement is that the inter-arrival time of the
packets should not exceed some value. Telemetry applications will
normally be adding data to a large data base for later offline

2



processing, in which case delay is not a significant factor, although in
some cases a fast response may be required. Processing efficiency will
be achieved, however, if the updating process can be scheduled regularly
with a high probability of there being data available to process; this
applies to both telemetry and voice data.

Stream traffic, therefore, can best be serviced by ensuring that
the regularity of the data flow is maintained. The role of the catenet
is to avoid congestion in the gateways (and elsewhere in the catenet
where possible), by giving these stream packets priority in the gateway
queues. A consequence of this definition of stream traffic support is
that it becomes meaningful for the catenet to offer a number of distinct
priority classes, rather than simply flagging the packet as 'priority',
as priority becomes a defined function of the gateways. The gateways
may well attempt to support priority classes within a network in
addition. In this case, the map between the standard internet priority
classes and the local priority classes will be a matter for the
implementation of the gateway half for the local net.

Priority is not, in itself, a guarantee that the packets will be
delivered with an acceptable degree of packet loss. The gateway
blocking techniques of (Cerf77) are not allied with any mechanisms for
signalling other gateways, and hence it is likely that packet loss will
occur in bursts. As I noted above, such bursts should be avoided; this
requires more sophisticated flow control procedures than are currently
used between the gateways.

Bulk Transfer Traffic

This traffic type is characterised by the movement of a continuous
stream of large packets, all of which must be delivered reliably from
end to end. One requirement of the catenet which has been proposed is
that this stream be delivered from end to end in the shortest possible
time (Cohen78). At first sight, this is the same requirement that
interactive traffic has. However, there are a number of critical
differences connected with the size of the transfer. Firstly, the delay
constraint is much less stringent than it is for interactive traffic;
the requirement is that the whole body of data be transferred in the
minimum time rather than that any portion of it be so transferred.
Moreover, in many circumstances the bulk transfer will be run as a batch
process, in which case there may be no delay constraint at all. The
potential volume of data involved also means that the capacities of the
channels available do become a significant limitation on the transfer
time, as they govern the point at which delays for individual packets
start to increase as traffic builds up. For this reason, a throughput
measure is a significant figure for bulk transfer traffic - it
represents the normal operating conditions of the network.

Underlying both these comments is the fact that the service
requirement for bulk transfer traffic is not packet based - it refers to
the whole of the transfer. This is very different from the stream and
interactive cases, where one can define service support on a per-packet

3



basis. Depending on the particular application we may wish to select
priority and delay classes. However, the feature of the catenet that
uniquely affects bulk transfer is the capacity of the networks and
gateways. In a virtual circuit situation, this might lead us to set up
a circuit based on maximum capacity paths, but with dynamic routing in
the catenet, this is not possible.

Within the current protocols, the best support we can give to aid
bulk transfers is to minimise packet overhead using the "Don't Fragment"
option. This has the disadvantage, however, that packets must either be
dropped, rerouted, or fragmented according to a private protocol if they
encounter a net whose packet size is too small (Shoch78). Since the
internet protocol makes no guarantee of reliability (Postel78), such
packets will most likely be dropped unless the routing algorithm is
modified to meet this restriction. That is, for packets with the "Don't
Fragment" bit set, the routing algorithm should only consider routes
contained entirely within the subset of nets within the catenet which
have packet sizes such that fragmentation is not necessary. This
clearly has a major effect on the routing algorithm, as it means that
the gateways have to keep track of all possible paths, as well as a
record of the maximum packet sizes. Moreover, for packets larger than
some critical size, there may never be a path in the catenet which is
capable of supporting the packets without fragmentation. In this case,
the maximum packet size supportable by the catenet on an unfragmented
basis is a parameter which must be known by the end processes. In the
worst case, in fact, this number may differ depending on the two
terminal networks involved.

If the network dependency introduced by the "Don't Fragment" bit
ever does become a serious problem, it is most likely to be with bulk
traffic, as this service uses the largest possible packet sizes. It is
not a general solution to supporting efficient internet transmission.
In practise, however, the problem can be mitigated by making use of
private fragmentation/reassembly protocols at the right points, which
will have the effect of disguising the maximum packet sizes. Where the
limiting maximum packet size is governed by a long-haul backbone
network, such as the ARPANET, such a private protocol will be absolutely
necessary to permit a reasonable end-to-end service.

An alternative is to formalise the existence of gateway-to-gateway
fragmentation and reassembly by allocating an option bit "Attempt
Reassembly" in the internet protocol, which will be an instruction to
gateways to attempt to reassemble the fragments of a packet into larger
units, where possible. This option implies that all fragments of a
packet must be sent to the same gateway on each internet hop. It also
requires that fragments must be stored in the gateway for a certain
period before being forwarded, if a gateway decides that reassembly may
be possible. Depending on the likely instability of a particular
internet route, the first requirement may or may not be a stringent one.
The second constraint is more serious in its implications. To be
operated effectively it requires that the gateways take steps to avoid
congestion and packet loss forcing end-to-end retransmissions, which

4



would defeat the purpose of minimising packet overheads. In short, it
is essential for an "Attempt Reassembly" strategy that there exists
effective gateway-to-gateway flow control.

Neither option is entirely satisfactory as a way of supporting
efficient transfer in a catenet with the current procedures. The
question needs further study.

Conclusions

The three traffic types may be given service support in ways
particular to each type. This support may be summarised as follows:

Interactive Traffic - Minimise delay
Stream Traffic - Minimise congestion
Bulk Traffic - Minimise packet overheads

Each of these will directly affect a particular area of the catenet
structure, respectively: choice of object function for the routing
algorithm; packet queueing techniques inside the gateways; and the
fragmentation and reassembly of internet packets. The area in which
service support is most unclear is bulk traffic. Further study of the
tradeoffs between possible techniques is needed here.

Ultimately, of course, types of service offered will be chosen by
the user both on the needs of his application and on his willingness to
pay the charges incurred. Because the services required are application
dependent, it is important that service types be offered explicitly as
minimising delay etc rather than tying them directly to a particular
traffic type. In this way the user will be able to choose the
combination that best suits his needs. While there is a simple way of
providing standard internet priority classes, it is not clear that this
can be done so easily with delay classes, while with efficiency it is
not clear that anything can be done in terms of grades of service - only
an all-or-nothing service has been discussed here.

One point that emerges clearly is that support of internet services
depends heavily on the existence of gateway-to-gateway flow control, to
produce acceptable rates of packet loss for stream traffic and to permit
the tying up of gateway buffers for intermediate reassembly strategies.
The need for flow control and exchange of status information between
gateways was argued in (Bennett77). The high rates of packet loss in
both the gateways and the gateway/SIMP VDH links at high data rates in
the SATNET gateways (Treadwell78) is directly attributable to the
absence of gateway-to-gateway flow control. Such subnet effects can
only degrade internet performance still further.

5



References


Bennett77 - C. J. Bennett, A. J. Hinchley, S. W. Edge, "Issues in
the Interconnection of Datagram Networks" IEN 1

Cerf77 - V. G. Cerf, "Gateways and Network Interfaces" IEN 6

Cohen78 - D. Cohen, Private discussion

Postel78 -J. Postel, "Internet Protocol Specification" IEN 41

Shoch78 - J. Shoch, "Inter-Network Fragmentation and the TCP" IEN 20

Strazisar78 - V. Strazisar, "Gateway Dynamic Routing" IEN 25

Treadwell78 - S. W. Treadwell, "SATNET Gateway Calibration
Measurements" PSPWN, number to be assigned