home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rsvp / rsvp-minutes-94jun.txt < prev    next >
Text File  |  1994-11-02  |  5KB  |  168 lines
  1.  
  2. INTERIM_MEETING_REPORT_
  3.  
  4. Reported by Bob Braden/ISI and Lixia Zhang/Xerox PARC
  5.  
  6. Minutes of the Resource Reservation Setup Protocol Working Group (RSVP)
  7.  
  8. An interim meeting of the RSVP Working Group was held via the Mbone on
  9. 23 June 1994.
  10.  
  11.  
  12. Implementation Status
  13.  
  14. Steve Berson reported that ISI has implemented the current packet
  15. format, including variable-length flowspecs, filterspecs and
  16. authentication fields.  They still need to do teardown messages.
  17.  
  18. Don Hoffman reported that Sun has a revised version based on ISI code.
  19.  
  20. Dave Clark reported on MIT's implementation of CSZ packet scheduling in
  21. the kernel.  An issue that remains open in the packet scheduler is how
  22. should link sharing be set up?  MIT hopes to make the code available
  23. before the Toronto IETF.
  24.  
  25.  
  26. Open Issues
  27.  
  28. Bob Braden went through a list of major open issues:
  29.  
  30.  
  31.    o Interaction between RSVP and routing:  Estrin will give a progress
  32.      report at the Toronto IETF.
  33.  
  34.    o Negotiation/reservation model:
  35.       -  One pass versus two pass versus one pass with advertising:
  36.          Shenker will make a presentation at the Toronto IETF.
  37.       -  Distinction between Tspec and Rspec.
  38.       -  The ``killer reservation'' problem.
  39.  
  40.    o API: Can we do anything to insulate applications from future RSVP
  41.      changes, e.g., what flowspec should be used in API?
  42.      Bradley feels that compatibility with WinSoc (socket interface for
  43.      Windows) should be looked into; he will channel contact information
  44.      to Braden.  Hoffman feels that communication with IEEE 802.1 group
  45.      is needed.  Wroclawski reported that the INTSERV Working Group
  46.      plans to talk to the IEEE 802.1 group.
  47.  
  48.    o Authentication:  Can we get short-term use out of this field?
  49.  
  50.    o Link sharing (brought up by Clark):  Is link sharing ready for
  51.      prime time or still on research agenda?  Moy reported that Proteon
  52.      supports it already.
  53.  
  54.  
  55.  
  56. RSVP Specification Walk-Through
  57.  
  58. Bob Braden led a walk-through of the RSVP specification.
  59.  
  60.  
  61.    o The term ``session'' [2.1]
  62.  
  63.      Wroclawski:  Consider case of multiple related mcast groups for
  64.      same application instance, e.g.  for layer-coded video; need more
  65.      complex terminology.
  66.  
  67.      Braden:  it's adequate for the time being.
  68.  
  69.    o Reservation styles [2.2]
  70.  
  71.      Specification of dynamic filter style appears to still have a
  72.      problem.  Berson thinks there is intermediate solution between
  73.      original form (no merging) and current form.
  74.  
  75.      Estrin:  are we proposing to rethink reservation style as a whole,
  76.      or fix the current problem?
  77.  
  78.      Van:  the only way to fix dynamic filter style is to delete it.
  79.      Does not seem to fit IP operation mode well.
  80.  
  81.      Braden:  Different styles have turned out to each be special case,
  82.      whereas one would expect them to each fit clearly into a larger
  83.      structure.
  84.  
  85.      Wroclawski:  We should develop larger structure.
  86.      Shenker and Lixia:  will revise and resend resend an old message
  87.      about reservation styles to RSVP mailing list.
  88.  
  89.    o Merging reservations [2.3.3]
  90.  
  91.      Shenker volunteered to rewrite the merging section of the spec
  92.  
  93.    o Teardown [2.3.4]
  94.  
  95.      Braden:  we believe it works but we have not tested
  96.  
  97.    o Examples [2.4]
  98.  
  99.      Berson:  add an example of hierarchically encoded video
  100.  
  101.    o Host model[2.5]
  102.  
  103.      Braden:  RSVP is nondeterministic in nature, unpleasant to
  104.      applications
  105.  
  106.      Wroclawski:  propose a deterministic interface, ask what are the
  107.      tradeoffs
  108.  
  109.    o Soft State Management [3.3]
  110.  
  111.      Braden:  the tradeoff between short and long refresh periods.
  112.  
  113.      Wroclawski:  should we have an adaptive refresh period?
  114.  
  115.      Lixia:  the principle is that RSVP uses soft-state and refresh as
  116.      last fence against failure -- RSVP will repair itself even if
  117.      everything else fails.  but for performance optimization we need to
  118.      get signals from routing protocols.
  119.  
  120.      Van:  congestion worry--when congested, lower quality, do you want
  121.      to send more refreshes?
  122.      He suggests RSVP do pairwise (i.e.  between neighbor nodes)
  123.      adaptive refresh as in PIM
  124.  
  125.    o Error messages [3.1.3]
  126.  
  127.      Open issue regarding where to send failure notification of merged
  128.      reservation requests.
  129.  
  130.      Need to be taken into consideration for merging design (Shenker)
  131.  
  132.    o Flowspec Format [3.6.1]:
  133.  
  134.      Hoffman:  Sun used CSZ flowspec, but used BW field only
  135.  
  136.      Wroclawski:  flow spec should be extremely simple
  137.  
  138.      Hoffman:  Maybe not.  Include complexity of network, use interface
  139.      in host to insulate applications from complexity.
  140.  
  141.      Shenker:  are we arguing about the flowspec that int-serv is yet to
  142.      work out?
  143.  
  144.      Van:  two choices
  145.        1 NP complete problem:  each of all applications tries to say want
  146.          they want
  147.        2 simple problem:  network says ``this is my capabilities''
  148.  
  149.      Shenker:  we are doing the 2nd
  150.  
  151.      Wroclawski:  no you're doing the fist--your flow spec
  152.  
  153.      Clark:  abstract way to express what applications need -- perhaps
  154.      we should stand somewhere between the two
  155.  
  156.    o Filter spec:  should we think more general filter spec?
  157.  
  158.      Wroclawski:  depends on how other parts play out, e.g.  whether a
  159.      flow ID may appear in future
  160.  
  161.  
  162. Conclusion
  163.  
  164. The meeting did not generate many specific suggestions for improvement
  165. of the specification prior to the Toronto meeting.  However, the group
  166. did identify a number of issues for discussion in Toronto.
  167.  
  168.