Subject: service models compared roughly

From: Jon Crowcroft <[email-masked]>
Date: Sun, 29 Jan 95 13:50:14 +0000

excuse the formatting - 

------------------------------------------------------

     A Rough Comparisonof the IETF and ATM Service Models
                   JonCrowcroft, UCL CS

                     January29, 1995

1Abstract

In this  memo,  we compare  the  emerging models  for  multiple
integrated traffic services that are  being devised by the IETF
andATMF working groups.

2Introduction and Rationale

The Integrated  Services Working  Group of  the  IETF has  been
workingtowards a service model for the future Internet[intserv].
Meanwhile, various standards groups have been working towards  a
service model for traffic management in ATM networks.   The ITU
andATM Forum are both active here.[uni][uni4][garrett]
  While  in  some  senses ATM  is  a  lower  level  switching,
multiplexing and  networking technology  than IP,  it is  valid
to compare the  service models that  these two  communities are
evolvingfor a number of reasons.

1.  There is  some validity  in  the view  that they  will  be
    competing technologies  -  ATM LANs  are  aimed at  direct
    connection of hosts, even though the wide area ATM carriers
    maynot make cell level services available.

2.  The IP  service model  has  to be  implemented on  top  of
    something.  If that something (medium) is shared with other
    protocolsstacks or IP traffic that is not following service
    commitments, service commitments must be honourable for the
    IPflows.  If the underlying medium is not shared with other
    traffictypes, it is still useful to consider direct support
    for the IP services  via the underlying services.   Simple
    scenariosare:

                           1


     o  IP and  IPX on  an  Ethernet -  here  no matter  what
        commitment novel multi-service routers might make,  the
        non-deterministic delay bound  provided by the CSMA/CD
        makes any  assurances null  and  void unless  the  IPX
        traffic is subject to similarentry requirements to the
        IPintserv ones.

     o  IP traffic over a set of  routers interconnected by an
        ATM cloud - here, the entire service model required by
        IP might be feasibly supported by the ATM layer, given
        a good enoughmatch, thus leaving the routers to simply
        implementthe IP framing and routing functions.

3The Service Models

Theorigins of the service model species for ATM and IP are very
different.
  ATM is  designed  based around  virtual channels,  paths  and
circuits, with an  explicit call setup  and teardown mechanism.
The expectation is that the  minimum service is as robust  as a
telephone call.  The obvious implementation of a single service
ATM network is to use round robin servicing of queues, ensuring
fairand near constant delay.
  IP is designed around  survivable topologies, and intelligent
end system recovery, and thus treats  each packet as it arrives
at each hop as best it can.  The  natural implementation for an
IP router is to use FIFO queuing.   Subsequent packets need not
followthe same route.
  This leads to  one fundamental difference not  often remarked
on:  packet ordering.   ATM guarantees cell  ordering, while IP
doesnot guarantee packet ordering.
  In extending the  service models to permit multiple  types of
service,the goals have been somewhat complementary.
  In the  case of ATM,  support starts with  the assumption of
existing Constant  Bit Rate  services  (digital circuits),  and
furtherservices are a relaxation of the bandwidth guarantees and
timingconstraints for these.
  In the  IETF, the Integrated Services  model starts from  the
assumption of a  best effort service  (typically implemented as
FIFO queuing with ``drop-tail''  behaviour under overload),  and
refines this to add  guarantees of various kinds,  typically of
delayvariance, bounds, and then throughput.

                           2


4Link Sharing, Network Provision Models

The Internet is  provided by a  huge number of  organisations -
often many more in a  single country as there are  PNOs (Public
Network Operators -  a.k.a.   PTTs) world  wide.   Subscribers'
traffic shares links.  Even agencies and providers share links.
A Key requirement for many of these agencies is to have service
commitments for their aggregated  traffic on a  link basis (the
mostexpensive resource in the long haul nets still, at least in
Europe, and also in sparselypopulated regions of the world such
asthe Pacific Rim, South America andmuch of Asia).
  At the  root of  all service  classes in  the IETF,  then is
the link share, followed by  other classes - we will  see below
whetherthis has further effects.  Link sharing is also sometiems
referred to as policy routing  - in fact it is  the microscopic
ratehr than topological component of policy routing:  that piece
ofpolicy that applies to flows ona single link.
  Of course, a similar effect canbe achieved on ATM networks by
building virtual path routing functions, but there is no way of
identifying these classes in call setup time.   In link sharing
in IP, the end user does not have to be aware of the policy for
anyupart of the topology - in a circuit model, each call has to
havethe policy exposed to the call setup mechanism (at the very
leastat every instance of NNI, if not at the UNI). (i.e.  there
appearsto be no relationship between E.164 or other address, and
agency, and route, and service class).  There  is no tag in the
packetto identify any of these factors either.  Thus exhaustive
databaseswould have to be used tofulfill this function.

5Delay or Throughput First -Any Effect?

The services in  ATMF are characteresed  first and  foremost by
"reservation of a ?BR" where ?  = UAVC...  whereas the services
inthe IETF are characterised by thedelay.(1)

--------------------------
1.  Clearly,   historically,  the  approaches   are  simply  a
consequence of provider views based  on charging for bandwidth,
whereas we might want to charge for reliability of delay rather
thanbandwidth,  and let theuser specify their contract with the
net in terms of  this - for  example, 100a user  happens to be
sendingwould imply that the user wont tolerate any less resource
(i.e. a "reservation" if you like.)

                           3


  Although  both agree  on this  (the ATMF  say  ``single most
important distinction among applications is the  real-time delay
constraint'' and the IETF say ``per-packet delay is the central
quantity about  which  the  network makes  quality  of  service
commitments.''  where the difference makes itself feltis in how
thisleads to implementation.
  The IETF model  does not prescribe resource  reservation, per
se -  it is  in some  sense less  restrictive:   You can  have
reservation, but you might have infinite bandwidth on some hop,
or some network; what you  must have is a schedule  across each
provider stage  that meets  the end  to end  latency and  delay
variance.   Saying you  also have to  meet the  bitrate may be
overspecifying the requirement.  In the  limit, a provider is a
hop, so the  delay constraints may  be only need to  be end to
end.  Of course, the IETF then refine this to say,  if you need
to reserve resources, you  need to commit bandwidth  as well as
buffers.  This there is the need for all of the mechanisms such
as resource reservation,  admission control  (decision based on
availableeffective bandwidth and policies on loss and delay) and
policing.[rsvp]
  Now, can  we unify  an approach  that starts with  the delay
variance(which is in fact a dependent variable on the number of
different flows) with an approach that starts with the bandwidth
andits variance?

6Traffic Service Class Heriarchies

In our view, delay is the  dependent variable.   If we allocate
traffic to a link that operates statistical multiplexing,  (i.e.
non-quarantined traffic classes), then  we anticipate delay  and
loss increases  as  further traffic  of  that class  is  added.
Further,we might envisage a class hierarchy of traffic services,
andallow bandwidth borrowing/lending up and downthe hierarchy.
  The ATMF  and IETF  have very similar  traffic classes  right
now, but the IETF ones fit in a hierarchy,  while the ATMF ones
typicallyrepresent a spectrum:

ATMFspectrum:

CBR... VBR ... ABR ... UBR.

                           4


  It has  been suggested  that  the ATMF  model can  be viewed
hierarchicaly,  but  the  ambiguity  of  where  to place  some
applications shows that this is  not final - however,  one view
couldbe:

ATMF"Hierarchy"

            services
             /     \
        real-time   non-real-time
           _        _
 simple:    CBR      UBR
           _        _
 fancy:    VBR      ABR

IETFTraffic Service Class Hierarchy

               LinkShare
                 _
          ```````````````````
          _               _
     Guaranteed        Best Effort
      _      _        _        _
delaybound  predictive  fairshare traditional

  At the bottom of the IETF hierarchy, the match is very close,
with the exception that at the moment, ABR implements a minimum
rate where a pure FQ system would simply offer  a fair share of
available bandwidth with the minimum rate set to 0  only.  This
is good, since,  for the Internet  at least,  most applications
cannot make any statements about minimal bandwidth, but in other
protocolstacks (e.g.  DEC LAT as a trivial example) thissort of
statementcan be made, yet they arenot strictly VBR.

7Borrowing and Replacement Strategies

The model  of  a  shared  network  is  one  that  gains  cost-
effectiveness  in  terms  of  dimensioning  by  using   sharing

                           5


mechanisms at all  possible levels.    Thus the  IETF model  of
serviceassumes that within a service class that can be degraded,
we may also specify  the rules for  how it can  be degraded by
instances of  traffic classes  from other  services.   This  is
important, as  in distributed  applications such  as multimedia
conferencing, wemay have flows that are degradable (e.g.  video
may be lost in favour  of audio and whiteboard), and  these may
be from many sources  (so simply using  VPs to do  this is not
sufficient).   On a  larger scale,  one could imagine  managing
all the traffic  of different media  types from world  wide web
servers[www], and allocating distributedtraffic trading rules.

8Ordering and Routing

Dynamic routing is often invoked as a key to the success of the
Internet.   In fact,  routes change rarely  (or else too  often
during route flaps).  What is useful  about the router model is
that the topology discovery  allows the network to  grow at the
edges.
  In the  RSVP  work, to  make traffic  guarantees  stick, and
to permit computable solutions  to multiple-metric routing,  the
suggestionhas been made that routes associated with reservations
should be pinned (this also  reduces a possible n-pass exchange
to one pass, plus the pin-pass).   This will also remove packet
re-ordering(at least gratuitous re-ordering).

9Conclusions

The ATMF are, like  all good standards bodies,  trying to avoid
overspecifying.   The model  of the  network is  a cloud,  with
a clear  User to  Network Interface  which  is the  contractual
measurement point.    The IETF  see the  network as  consisting
of many  routers, which  in practice  might  each be  subjected
to a Bradner(ng)  test[bradner], to  see the  effect on  timing
reconstruction(or burst to jitter conversion) of various traffic
mixes.  In some  senses, the latter is  simply a micro-economic
modelof the former.  However, one thing that it does lead to is
a prescription for scheduling classes which implement particular
queuing disciplines  which  result in  the  ability to  support
particular mixes of traffic flows from particular proportions of
classes.
  Of  course,  only (provider)  policy  can  state what  these
proportions of different  classes should be,  but from  a given

                           6


schedule, it  is  then  possible to  calculate  the  cases for
occupancy of various classes.  Thus, for example, the IETF have
advanced further in aiding implementation, by proposing specific
admissiontests for given schedules.  (Seefor example [admit]).
  In fact, they go further and state that Weighted Fair Queuing
withPriorities is a scheme that is sufficient enough to support
all the  range of  classes in  the hierarchy  above if  applied
correctly. A highly flexible framework for implementing this was
presentedin[cbq].

Acknowledgements

Thanks to Mark Garrett of Bellcore  for extensive feedback, and
the usual help  from all  of Bob  Braden of  ISI's End  to End
ResearchGroup discussions.  Misconceptions are mine.

References

References

[rsvp]Zhang,   L.,  Braden,  R.,  Estrin,   D.,  Herzog,  S.,
     and S.Jamin, "Resource  ReSerVation Protocol (RSVP),  IEEE
     Network,1993.

[admit]Jamin,  S.,  Shenker,  S., Zhang,  L.,  and  D. Clark,
     "An Admission Control  Algorithm for Predictive  Real-Time
     Service", Extended abstract, in  Proc. Third International
     Workshop on  Network  and  Operating  System Support  for
     Digital Audio and  Video, San Diego,  CA, Nov.  1992, pp.
     73-91

[intserv]R. Braden, D. Clark, S. Shenker, "Integrated Services
     in the Internet Architecture:  an  Overview.", 06/09/1994,
     RFC1633

[uni]"ATM  User-Network Interface  Specification Version  3.0",
     EnglewoodCliffs, NJ: Prentice Hall, September 1993

[uni4]The ATM  Forum, "ATM Forum Traffic Management  Specifica-
     tion Version 4.0" Expected to  be Published July 1995. (A
     non-public working draft exists in ATM  Forum contribution
     95-0013,February 1995.)

                           7


[garrett]M.  W.  Garrett  "ATM Service  Architecture:    From
     Applications   to   Scheduling"   ATM   Forum   contribu-
     tion   94-0846,    Sept   1994.   available   at    URL:
     ftp://thumper.bellcore.com/pub/mwg/ATMF.qos.mwg

[www]T. Berners-Lee,  "Universal Resource Identifiers in WWW: A
     Unifying Syntax for the Expression of Names  and Addresses
     of Objects on the Network as used in the World-Wide Web",
     06/09/1994, RFC 1630

[bradner]S.  Bradner,  "Benchmarking Terminology  for  Network
     InterconnectionDevices", 07/02/1991. RFC 1242.

[cbq]Wakeman, Ghosh, Crowcrodt, Jacobson and Floyd, "Implement-
     ing Real Time Packet  Forwarding Policies using  Streams",
     Usenix,New Orleans, January 1995.

                           8

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 30 Jan 1995 14:51:07 -0500

Jon,

> IETFTraffic Service Class Hierarchy

Where did this com from?

I thought it was something like:

		real time				elastic
	   delay-sensitive  playback		interactive  bulk-transfer
	intolerant	rate-adaptive	

where reservations could be either predictive or guaranteed.

I also though it was not a strict hierarchy.  You could zigzag withing
real time and have "real time, playback, intolerant" (example: voice
mail retrieval to dumb handsets) and "real time, delay-sensitive,
rate-adaptive" (example: vat).

Curtis