Subject: Minutes of RSVP WG meetings

From: braden (Bob Braden)
Date: Thu, 14 Apr 1994 16:59:04 -0700

Seattle IETF Meeting Proceedings

Transport Service Area
RSVP Working Group

Current Meeting Report

Reported by: Bob Braden/USC Information Sciences Institute
           and Lixia Zhang/Xerox PARC

Minutes of the Resource Reservation Setup Protocol Working Group (RSVP)

Agenda - Tuesday Session:

   o Organization of Working Group
   o Introduction to RSVP
   o Implementation Status

This was the first meeting of the RSVP Working Group, whose objective
is to standardize the specification of the reservation setup protocol
RSVP.  RSVP will operate within the framework of the integrated
services architecture that is under development by the int-serv WG.
Therefore, some protocol/implementation details will have to be
developed in parallel or jointly between the two WGs (in particular,
the flowspec and the interface to admission control).  However, the
urgency of deploying realtime service in support of multimedia across
the Internet forces this course of action.  The planned approach is to
do phased development of RSVP specifications through successive
versions as the integrated service requirements develop.

Bob Braden presented an introduction to the current draft RSVP design.
(See overheads later).  This presentation covered the assumptions and
fundamental ideas behind RSVP, its service model, and its protocol
mechanisms.  Steve Berson then gave a short presentation on a prototype
implementation of the current RSVP specification, which is being tested
and developed in DARTnet.

ISSUES RAISED

A number of important questions were raised by attendees.

1. Reservation Model

    RSVP uses a 'one pass' reservation model, which is intrinsically
    unable to perform fine grain 'delay budget' allocation across the
    routers in the path, as does by Berkeley Tenet group proposal.  The
    question that was raised was whether this is adequate.  One
    response is that such fine grain delay allocation is not especially
    useful in general, and the issue was tabled for further discussion
    at the second session.

2. Recovery from Reservation Failure

    RSVP is currently designed to be as nearly as possible decoupled
    from routing, to achieve the advantages of modularity.  This means
    that RSVP tries to establish a new reservation using a (primary)
    route given by the routing protocol at the request time.  The
    question is then: what happens if there is not enough capacity to
    satisfy the request along the primary route, but an alternative
    route does have the capacity; how can the secondary route be used?

    Braden suggested that this situation requires some
    source-controlled routing mechanism to find and install secondary
    routes, and that such source-demand routing protocols are being
    developed (e.g., IDRP, SDRP) and will be use by RSVP when they
    become available.  However, the general area of the interface
    between RSVP and routing does need to be considered and architected
    in this WG.

3. Mobility, Route Flapping, and Load-Dependent Routing

    A concern was expressed that RSVP would be unable to handle
    mobility.  However, it appears that mobile hosts are only a special
    case of the general problem of changing routes.  This is an
    important issue, and this WG must convince itself that RSVP will
    work satisfactorily in the presence of mobility.

    We may categorize route changes into three types: absolute (where
    the old route is unusable), permissive (where the current path is
    not broken, but a "better" path is now available), and "route
    flapping" (routes constantly switching between alternate paths).
    Permissive route changes are stable (i.e. the route changed for a
    reason and will NOT go back to the previous one spontaneously),
    while route flapping is unstable.  RSVP currently adapts to route
    changes by reserving resources on a new route after it is
    established.  This may create a brief gap in the reservation
    protection for a flow's data.  These gaps may be unavoidable for
    absolute route changes, but they are undesirable for permissive
    route changes and will almost certainly be a problem in the case of
    route flapping.

    It was also suggested that the routing used by RSVP should be
    constantly adjusted according to the available capacity.  Those who
    were aware of early ARPANET experience with load-dependent routing
    were less than enthusiastic about this approach, which could easily
    cause routing instability.

4. Path Messages

    It was asked how we can be sure that Path messages follow the same
    path through the multicast trees as the corresponding data.
    Braden noted that whatever information in a packet may be used to
    determine the multicast routing of the data packets (e.g., QOS
    bits) must also be contained in Path messages, which must follow
    the same routes.

    The question was raised of whether or not Path messages are needed
    at all.  This is a complex issue that was tabled.

Agenda - Thursday Session

    o Packet Classifier: Theory and Measurements
    o Open technical issues
    o Specification document
    o Implementation and testing strategies

CLASSIFIER

John Wroclawski described the function of packet classification and
presented experimental results on a Patricia-tree-based classifier.
The most significant result was that Patricia tree classification
requires a roughly constant CPU time as a function of the number of
classes is roughly constant (i.e., the logarithmic term has a very
small multiplier).  The time per packet (in usec) was measured to be:

     Hit Rate      DEC 3000/600   Sun Sparcstation 1+

       100%         10 usec/pkt    47 usec/pkt

        50%         11 usec/pkt    62 usec/pkt

TECHNICAL ISSUES

In response to issues (2) and (3) raised at the first session, Deborah
Estrin made a brief presentation of proposed routing protocol
enhancements to aid RSVP.  These include:

    a. Reverse Path Routing, i.e. a future routing protocol will be able
       to give a receiver the "Shortest Path FROM" the sender.

    b. Route Pinning, i.e. stable routes over the life time of flows.

    c. Alternate path routing if setup attempt fails.

    d. Route selection based on configured capabilities (e.g. IDRP QOS
       routing)

    e. Route selection based on estimate of resource availability 
	(e.g., SDRP path explorer and reject information used)
	(Admission control gives information to routing protocol)

She concluded with the remark that people working in the routing area
are well aware of the requirements to better support applications and
protocols such as RSVP, and progress is underway.

With respect to  the one-pass reservation model used by RSVP (issue 1 at
the first session), Bob Braden and Scott Shenker took an action item to
prepare a short summary of the tradeoffs that this implies.

Lixia Zhang then made a presentation on two open design issues in
RSVP: route pinning and the tradeoff between using multiple multicast
addresses vs. filters to select subflows. (See the presentation slides)

a.  Route Pinning

    During the RSVP BOF held at the last IETF (Houston), a concern
    voiced by several people was the impact of route flapping on RSVP
    reservations.  Because RSVP reservations are made along the routes
    given by routing protocols, constant route flapping between
    alternate paths would lead to unstable service.  Although we firmly
    believe that route (in)stability is a routing protocol problem and
    should be solved there, nevertheless a "route pinning" scheme was
    proposed and presented for the WG's evaluation (see Lixia Zhang's
    presentation slides for details).

    No detailed comments about the scheme were received during the
    discussion.  John Wroclawski raised the related issue of permissive
    route changes: should RSVP should ensure a graceful transition from
    an old route to a new one when the route has permanently changed,
    e.g., by pinning the data flow on the old route until a reservation
    has been made along the new route?  This would address the "mobile
    host and route transition" concern raised at the first meeting.
    John noted that addressing this issue may take care of route
    flapping as a side effect. This issue deserves further discussion
    by the WG.

    Considering the issue of route flapping, Curtis Villamizar argued
    that, based on his observation from NSF backbone routing table,
    route flapping is not a serious threat in today's networks.
    Moreover, Van Jacobson argued strongly that we must take a firm
    stance in favor of fixing routing problems in the routing protocols,
    rather than by adding complexity to RSVP.

    The consensus taken from the WG is to not include the route pinning
    in the current RSVP spec or implementation, though we may table it
    as an appendix item.

b. Multiple Multicast Groups vs. Filters

    RSVP separates reservations from usage by a packet filter scheme.
    The filter associated with each reservation  determines which
    packets can use the reserved resources.  Two different functions of
    the packet filter can be identified: distinguishing packets from
    different sources, and distinguishing packets from different
    substreams from the same source to meet heterogeneous receiver
    requests.

    Recently, Deering, Estrin, and others have suggested a modification
    to RSVP filter usage.  Their proposal would use separate multicast
    groups, instead of filters, to distinguish substreams within a
    single session.  Although the filter function would still be needed
    to distinguish different senders (for dynamic filter style
    reservations), the proposal would simplify the filterspec, because
    it would only need to distinguish data sources.  However, this
    proposal has a drawback: if sources use different encoding schemes,
    and if a receiver wants to receive different numbers of substreams
    from different sources (this can happen even with homogeneous
    encoding), then this request cannot be met using separate multicast
    groups for different substreams (but without distinction of
    sources).  It also requires that the different multicast addresses
    belonging to different substreams of the same session must be
    "bundled" in routing so that they will be guaranteed to have the
    same multicast trees.

    During the discussion Van Jacobson commented that, if multicast
    routing implemented per-source pruning (as well as reverse path
    routing), then the filter scheme could be completely eliminated
    from RSVP.  Because RSVP reservations ride "on top" of the routing
    protocol, under Van's scheme multicast route pruning would also
    prune any temporarily unused reservation that a DF reservation
    wished to keep.  Van later suggested a solution to this problem:
    use a separate multicast group address for DF reservation messages,
    separate from the multicast group used for data delivery.  Then the
    routing protocol could prune specific sources that no one was
    currently listening to, without pruning DF reservations.  This
    approach would also require bundling of multicast routes, to ensure
    that both groups (the one used by reservations and the one used to
    forward data) have the same multicast trees.

There was a short discussion of the current RSVP functional
specification document, and an outline of the changes that have been
incorporated recently or will be incorporated soon.

The group agreed to hold an MBONE conference before the next IETF
meeting (Toronto).  The date will be determined on the mailing list.