Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ien/ien-51

Text File | 1988-12-02 | 14KB | 297 lines

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