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.