INTERIM_MEETING_REPORT_

Reported by Bob Braden/ISI and Lixia Zhang/Xerox PARC

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

An interim meeting of the RSVP Working Group was held via the Mbone on
23 June 1994.


Implementation Status

Steve Berson reported that ISI has implemented the current packet
format, including variable-length flowspecs, filterspecs and
authentication fields.  They still need to do teardown messages.

Don Hoffman reported that Sun has a revised version based on ISI code.

Dave Clark reported on MIT's implementation of CSZ packet scheduling in
the kernel.  An issue that remains open in the packet scheduler is how
should link sharing be set up?  MIT hopes to make the code available
before the Toronto IETF.


Open Issues

Bob Braden went through a list of major open issues:


   o Interaction between RSVP and routing:  Estrin will give a progress
     report at the Toronto IETF.

   o Negotiation/reservation model:
      -  One pass versus two pass versus one pass with advertising:
         Shenker will make a presentation at the Toronto IETF.
      -  Distinction between Tspec and Rspec.
      -  The ``killer reservation'' problem.

   o API: Can we do anything to insulate applications from future RSVP
     changes, e.g., what flowspec should be used in API?
     Bradley feels that compatibility with WinSoc (socket interface for
     Windows) should be looked into; he will channel contact information
     to Braden.  Hoffman feels that communication with IEEE 802.1 group
     is needed.  Wroclawski reported that the INTSERV Working Group
     plans to talk to the IEEE 802.1 group.

   o Authentication:  Can we get short-term use out of this field?

   o Link sharing (brought up by Clark):  Is link sharing ready for
     prime time or still on research agenda?  Moy reported that Proteon
     supports it already.



RSVP Specification Walk-Through

Bob Braden led a walk-through of the RSVP specification.


   o The term ``session'' [2.1]

     Wroclawski:  Consider case of multiple related mcast groups for
     same application instance, e.g.  for layer-coded video; need more
     complex terminology.

     Braden:  it's adequate for the time being.

   o Reservation styles [2.2]

     Specification of dynamic filter style appears to still have a
     problem.  Berson thinks there is intermediate solution between
     original form (no merging) and current form.

     Estrin:  are we proposing to rethink reservation style as a whole,
     or fix the current problem?

     Van:  the only way to fix dynamic filter style is to delete it.
     Does not seem to fit IP operation mode well.

     Braden:  Different styles have turned out to each be special case,
     whereas one would expect them to each fit clearly into a larger
     structure.

     Wroclawski:  We should develop larger structure.
     Shenker and Lixia:  will revise and resend resend an old message
     about reservation styles to RSVP mailing list.

   o Merging reservations [2.3.3]

     Shenker volunteered to rewrite the merging section of the spec

   o Teardown [2.3.4]

     Braden:  we believe it works but we have not tested

   o Examples [2.4]

     Berson:  add an example of hierarchically encoded video

   o Host model[2.5]

     Braden:  RSVP is nondeterministic in nature, unpleasant to
     applications

     Wroclawski:  propose a deterministic interface, ask what are the
     tradeoffs

   o Soft State Management [3.3]

     Braden:  the tradeoff between short and long refresh periods.

     Wroclawski:  should we have an adaptive refresh period?

     Lixia:  the principle is that RSVP uses soft-state and refresh as
     last fence against failure -- RSVP will repair itself even if
     everything else fails.  but for performance optimization we need to
     get signals from routing protocols.

     Van:  congestion worry--when congested, lower quality, do you want
     to send more refreshes?
     He suggests RSVP do pairwise (i.e.  between neighbor nodes)
     adaptive refresh as in PIM

   o Error messages [3.1.3]

     Open issue regarding where to send failure notification of merged
     reservation requests.

     Need to be taken into consideration for merging design (Shenker)

   o Flowspec Format [3.6.1]:

     Hoffman:  Sun used CSZ flowspec, but used BW field only

     Wroclawski:  flow spec should be extremely simple

     Hoffman:  Maybe not.  Include complexity of network, use interface
     in host to insulate applications from complexity.

     Shenker:  are we arguing about the flowspec that int-serv is yet to
     work out?

     Van:  two choices
       1 NP complete problem:  each of all applications tries to say want
         they want
       2 simple problem:  network says ``this is my capabilities''

     Shenker:  we are doing the 2nd

     Wroclawski:  no you're doing the fist--your flow spec

     Clark:  abstract way to express what applications need -- perhaps
     we should stand somewhere between the two

   o Filter spec:  should we think more general filter spec?

     Wroclawski:  depends on how other parts play out, e.g.  whether a
     flow ID may appear in future


Conclusion

The meeting did not generate many specific suggestions for improvement
of the specification prior to the Toronto meeting.  However, the group
did identify a number of issues for discussion in Toronto.