CURRENT_MEETING_REPORT_ Reported by Claudio Topolcic/CNRI CIP Minutes Agenda o Status reports - COIP-K - ST-II - VT and PVP - SRI activities o Discussion - Analysis of COIP approach vs other CL approaches Meeting Report Guru, Claudio and Steve gave overviews of the status of the implementations that they are responsible for. Barbara gave an overview of the activities at SRI. o Benchmarks on DARTnet. o SFQ (based on source & destination IP addresses only) - implemented but not debugged. o SFQ + resource reservation - to work with ST, for example. o Writing an annotated bibliography on congestion control. o tg currently uses tcp or udp sockets; we need to add ST sockets and test. Benchmark results: BW, loss, delay; fairness, path utilization. Discussion of CO vs. CL Approaches 1 The purpose of this discussion was to understand the real differences between the approach taken by this group versus other, ostensibly connectionless, approaches that have been proposed, and where there are differences, to identify analysis, measurements, or experiments that would give us a better understanding of which approach is superior in which situation. Steve led a discussion of our understanding of an alternate CL approach. The following is a diagram of the modules that would have to be implemented in a router in order to support such an approach. ---------------------------------------------------------------- | ________________ _____________ ________ | | | Packet | | Resource | | | ------> | Identification |-----> | Enforcement |----> Queue |-----> | |________________| |_____________| ________| | | | _____ ^ | | | | | | | | | |_____| | | | --------> |_____|-------- | | | | Forwarding | | |_____| Table | | ^ | -------------------------- | ----------------------------------- | _______________ | | | Resource | | Manager | | | |_______________| We discussed what were believed to be differences in the approaches. 1. Classes vs. individual flows. A proposed CL approach may have ``classes'' that can carry traffic belonging to different flows. However, Guru's MCHIP protocol has PICons and Lixia's Flow Protocol (FP) has Flow 0, either of which can carry packets from any flow so are equivalent concepts. When you use a PICon, you have to include more addressing info than just the logical channel number, perhaps the full addresses. This raised the question of whether the short headers that ST and MCHIP use are worthwhile, and how often they would be used? 2 We may have a different view of the future. Will individual flows be small or large with respect to available bandwidth. If they are large, then identifying individual flows will be more important. If they are small, then perhaps it is better to aggregate a number of flows together. The answer may be different if we look at the short term or the long term. 2. Reservation request and the start of the data flow. There may be a difference as to the chronological binding of reservation to the time flow begins. We make the reservation at the time the flow begins. An alterate approach might allow a reservation ahead of time. There are some further issues, specifically, if the intent is to not do any work at the time the flow begins, then the system must be prepared to redo work as the topology changes. 3. Failure recovery. When a link goes down, connectionless protocols can reroute more easily if multiple paths exist. But in the CO scheme, we could use Flow 0 or PICon (or encapsulate ST in IP) along the alternate path without guarantees during the recovery. How fast will IP rerouting be compared to CO connection repair? One RTT? 4. Location of resource manager. The alternate approach allows the resource manager to be in a separate box from the router. A resource manager separate from the router allows a hot standby for redundancy, possibly fewer resource managers than forwarders, allowing the use of dumb, and therefore cheap, forwarders, and may simplify the transition from the current IP to an ``integrated services'' IP since the changes to the routers might be less so it would be easier to get the vendor to accept the change. However, it needs a reliable protocol between the resource manager and the forwarder, which must be standardized to allow mixing vendors and introduces a number tradeoffs, e.g., problems because the manager doesn't directly see connectivity changes. Further, we don't expect any difference in setup time required with separate resource manager vs. one combined in the router. 5. Transition path to the new system. A CL approach is presumed to allow an easier transition. However, how significant is it whether the first 20 bytes look the same as an IP header? In either case, new software must be installed in all routers that need to implement resource management. Host software may not need to change if resource management used only IP options since the existing BSD software allows IP options to be specified by the application. 3 6. Resource management. This is an issue regardless of the approach taken. Furthermore, in general, the same mechanisms can be used in both approaches. 7. Flywheel resource allocation. This is a scheme by which a router predicts the resource requirements of flows within a implicitly by monitoring past usage and assuming that the requirements will change slowly, that is, it has ``momentum''. If a new flow is detected which would overuse a class's resources, that new flow could be blocked. This approach requires keep-alives, may require further feedback to the applications, and does not interact well with pre-scheduling of resources. 8. Routing. A CO oriented approach doesn't need smart routing because the routes are verified anyway, allows for alternate path routing based on load whereas a datagram approach does not, because it is unstable. Further, we couldn't see how IP multicast would support dynamic flows efficiently. 9. Explicit vs implicit setup. A CO scheme, which naturally incorporates explicit setup, allows coordinated call blocking, which would allow for some set of related flows to succeed, rather than a random set. However, in an implicit setup scheme, the cost (delay) is the same if the setup fails, but much lower if it succeeds, which is presumed to be most of the time. On the other hand, doesn't just push the buck up a level (making the application decide if connection didn't work, vs. having explicit setup at a lower layer)? Experiments We identified a number of tests and experiments that could be conducted to try to tell which approach may be better under what circumstances. o Questions - Does blocking work? - How much interference comes from outages? - Do you honor scheduled calls? - Utilization? o Types of experiments: 4 - Measure lost bandwidth due to flywheel approach as utilization approaches saturation. - If CO implies enforcement per flow, and CL allows enforcement per class, which works better. - Failure recovery. * What is the impact of an outage on flows over paths that haven't failed (as failed flows are rerouted)? * How long does it take to reconstruct and what mechanisms are required in each case? * Measure time required to detect failure with various schemes. o What is the setup time? o How well are pre-scheduled flows honored? o Flip-side of (1): How much loss due to momentum of the flywheel (time the allocation is held after the flow stops) and what is the impact of reducing the timeout? o Which approach is better for correlated flows? Attendees Joe Blackmon blackmon@ncsa.uiuc.edu Andreas Bovopoulos andreas@patti.wustl.edu Helen Bowns hbowns@bbn.com Stephen Casner casner@isi.edu Barbara Denny denny@sri.com Zubin Dittia zubin@dworkin.wustl.edu Allison Mankin mankin@gateway.mitre.org Jay Melvin infopath@well.sf.ca.us Gary Mussar mussar@bnr.ca Andy Nicholson droid@cray.com Philippe Park ppark@bbn.com Gurudatta Parulkar guru@flora.wustl.edu Rehmi Post rehmi@ftp.com K.K. Ramakrishnan rama@kalvi.enet.dec.com Mark Schaefer schaefer@davidsys.com Brad Solomon bsolomon@hobbes.msfc.nasa.gov Martha Steenstrup msteenst@bbn.com Claudio Topolcic topolcic@NRI.reston.va.us Wing Fai Wong wfwong@malta.sbi.com 5 6