Notes from diffserv, March 15,1999, Minneapolis Chairs: Brian Carpenter and Kathie Nichols. Notes recorded by Scott Brim. Summary of where we're at and agenda bashing - Brian and Kathie Milestones and status: * Jan 99: Finalize EF draft, submit to IESG (done) * Feb 99: Publish boundary device model and MIB drafts (not done) * Feb 99: Finalize AF draft, submit to IESG (done) * Mar 99: Meet to finalize framework draft, discuss boundary and MIB draft (we are here -- boundary and MIB drafts are nonexistent, try to discuss on the list) * May 99: Finalize boundary and MIB drafts, submit to IESG * Jul 99: Meet at Oslo to review open issues Traffic conditioners are not listed as a milestone in our charter, although we're working on them. Chairs will update the milestones. Framework Draft (Elwyn Davies) Has not been a lot of input. Changes: * Emphasize scope: technical aspects. SLA -> SLS, S for " specification". TCA -> TCS. * Service scope added to TCS * Deployment scenarios added * Improved connections to MPLS, IPPM * Better coordination with diffedge and e2e (RSVP) drafts (still just drafts) * Noted major open issue of deploying multiple services on a DS domain * Multicast section improved (but not much in the way of solutions, mostly speculation) Issues, Orlando and now * Too many agreements * Cross coupling with other drafts * receiver control * coordination of PHBs interdomain * Lack of implementation experience o provisioning o deployment scenarios * Multicast Too many agreements: resolved by wording changes. "Agreement" -> "specification. Coupling with other drafts: useful to refer to diff-edge or its successor. draft-bernet-intdiff-00.txt is going to be a WG RFC inISSLL. Receiver control: wording revised as per Orlando minutes. Interdomain coordination of PHBs * Discussion thread on list * Marty Borden's PHB management draft (killed in Orlando) * Not raised specifically wrt this draft Provisioning * Too much theorising without implementation experience? * Too much discussion of possible mechanisms? * Go with it for now as the best available thoughts and revise in the light of experience? * Try to reduce the number of words used. Kathie: take out text about things where we just don't knowwhat we're talking about yet. Yoram: when we heard about EF and VLL service there was confusion about what a service was and how to make a service with a PHB. The framework has to be the place where that is done. Van: the framework does not reflect the VLL service accurately. The framework document should not describe specific services. It's currently writtenlike a standards document, but it isn't, there's no experience, thereare no operators involved in its formulation. Yes it should supplyadvice and overview and guidance, but it has musts and shoulds andother formalities. It's trying to codify things which we have no experience with. Kathie: the authors have a point of view of what services might look like which might not be the same as other people's point of view. They categorize services and put constraints on what might be offered. The authors request concrete comments. The two weeks after IETF will be exclusively for comment on the framework draft. After that we'll move on to the MIB and boundary documents. After that try again for last call. DiffEdge draft and MIB (Yoram Bernet) Had agreement to capture conceptual model in diffedge draft and put it in the MIB. Comments: * Not requirements, rather a conceptual model * Not just for boundary forwarders * Generalize egress traffic control * It's a superset of the diffserv functional blocks (not every router needs everything) * reduce emphasis on COPS * more on monitoring and SNMP * less on RSVP, more on NATs etc. that complicate it Review of model of ingress interface, packet forwarding, egress interface. A traffic conditioning block: Classifier at edge, meter/profile in center (e.g. token bucket), and action on edge (drop, mark, shape). (Kathie: meter is an active thing, profile is what you meter to. Token bucket is just one thing you can shape to.) The problem in general for this draft is that for the MIB, you need to be very specific, but in the framework you need to be general. So, what should be done with this? The intent was a conceptual model for diffserv routers. Fred: with respect to the MIB: a meter is always attached to something. MIB needs specifics. Consensus: make a conceptual model, requirements, to the extent possible, and make a generic MIB, to the extent possible, and when you need to get specific you make branches off this generic MIB. So ... Yoram moves forward, this becomes a WG document, eventually to be an informational RFC. Yoram produces the new version. Yoram uses his discretion when he doesn't get guidance from the WG. The next version of the MIB will be in 3-4 weeks. Two 3-color markers (Juha Heinanen) and more MIB discussion Two-rate and single-rate 3-color markers. Two-rate marks packets green, yellow or red based on two rates and two burst sizes. Useful when peak rate needs to be enforced. Single-rate 3CM marks packets green, yellow or red based on a rate and two burst sizes. Useful when only burst size matters. Can be color-blind or color-aware (honoring pre-existing colorings if they exist). Do not "borrow". A packet will only use up tokens from the color with which it eventually gets marked. Goal: publish as informational RFCs since they do not involve protocol issues. Juha says he wants something to refer to when telling the router vendors what he wants, and also can show to his customers to say how he will treat their packets. Generic MIB: well, if there is one he'll use it, but if not he'll use private MIBs. Raj Jain is concerned about making this a WG RFC, since there can be many markers. Walter Weiss: he thinks we need something concrete before we can move forward with MIBs. He wants to see some markers nailed down to write MIBs for. He wants something which we can use as a justification for a specific MIB model. Elwyn Davies: it does say in the architecture that when we produce PHB definitions we should publish parallel information about how they should be managed. Someone in the back: we don't know if the second one works operationally yet - needs balancing of parameters - so let's not adopt yet. Scott Bradner thinks it should be a standalone experimental RFC, not just an appendix to a MIB. It might be ready for a different track later. Informational says something will never be standards track material. Yoram Bernet: with the MIB you need information. You need classifier models, profile models, etc. Without them the MIB isn't useful. Raj Jain: If it's going to be a WG draft, wait a bit and analyze it more. Co-chairs: make it experimental. Put discussion of whether it works or not on diff-serv-interest. Have one more round of analysis and comment. TCP Friendly Traffic Conditioners (Shivkumar Kalyanaraman) These slides went by too fast, refer to them. The meaning of "TCP-friendly": * not necessarily TCP-aware * avoid per-connection burst loss * even isolated loss is bad for a TCP connection with a small window * probability of burst loss high when a large number of TCP connections are in slow start phase * optimization of provider metrics (utilization, queue length, packet loss rate) does not necessarily ... So ... * reduce probability of burst loss and TCP synchronization * convert aggregate burst loss into per-connection isolated packet loss. Also minimize per-connection loss instances * Protect small window connections from packet loss * ... By ... * RED or similar * control TCP rate or dampen TCP rate increases - control left, right edges of TCP window (rcv_wnd and ack#) and/or rate or release of loss * interleave * ... Results look useful, but hard to understand. Raj Jain: all of the meters so far lead to bursty losses, except this one. This is good. ATM Forum update (Marty Borden) The ATM Forum has agreed to support for diffserv and 802.1D. There may be spill over into the signaling group. A proposed list of requirements has been brought in. Solution approaches are still under study. Nothing normative yet. Sentiment that it's incorrect to try to map PHBs into ATM services. Want to map IP service into ATM service. Mappings and edge behaviors must be considered. Some are easily supported by the existing ATM infrastructure already (premium -> CBR or rtVBR for example). Several solutions propose signaling of diffserv information during VC setup. Internet2 Qbone update (Ben Teitelbaum) Review of Internet2 and and QBONE. I2QoS working group has met since July '97, starting with requirements. May '98, diffserv recommended. They are exploring the inter-domain problems. Building inter-domain testbed. Start with VLL/Premium service and EF. Lead and follow the IETF work. Everyone will support a well-defined SLS in a few months, using human BBs. Experimentation with pre-standards inter-domain BB signaling protocol (see Sue Hares). Inter-domain BB protocol (Sue Hares) Internet2 Qbone bandwidth broker advisory council. Look at BBs - don't care what happens within a domain, only between domains. Requests are aggregated. SLSs between domains, allocated in chunks of bandwidth. An individual BB will send changes to the other BBs, will query its local network, will have policy and management interfaces etc. Implementations: Telia, UCLA, Globus, Merit Diameter, BCIT,Hitachi. Diffserv-related efforts (moderated by Kathie Nichols) For all of these, see the drafts. Werner Almesberger, diffserv in Linux draft-almesberger-wajhak-diffserv-linux-01.txt. Web site is here. Can script essentially any kind of queuing discipline. Typical rates - a couple hundred megabits should be no problem on a PC. Future: simpler config management, measurements on EF, AF, policy management, currently endorsed for use in Quantum project (something like Internet2, in Europe). Tiziana Ferrari, diffserv coordinator for Quantum In April, will have an overlay network for several tests, including diffserv and multicast. See the QUANTUM test program. Dinesh Verma, DiffServ on Servers Why? What needs to be done? What needs to be standardized? Stub networks might be diffserv too, not int-serv (right). Avoid signaling overhead for short-lived low-throughput connections such as VoIP, web servers, transactions. More efficient mechanisms. Socket amortization. Application knowledge. IP security issues - mark before encrypting. Need socket level mechanisms, for shaping/marking/policing. Need diffserv on servers. Need an API. Need policy spec for diffserv (under policy framework group?). Need API for applications to talk to diffserv daemon (daemon? arbitrator?). Would like diffserv API to be working group RFC, informational. Applications shouldn't have to care if they are talking to RSVP or diffserv. Generalize QoS API. What do we do about diffserv and IPsec tunnels? See the end of the architecture RFC. IPsec has special considerations. See the ECN/IPsec draft for related discussion. Ion Stoica and Hui Zhang, Dynamic Packet State (presented in their absence by John Wroclawski) A whole set of rather flexible services, traditionally discussed in networks which do have state in them. Solution: stuff a bit of state in every packet. In draft talks about how to emulate FQ, WFQ, guaranteed service etc. Can work with as few as 10 bits. Can put them * in MPLS (e.g.) * extension header in IPv6 * use IPv4 fragment header o no visible effect outside DS domain o prototype freeBSD implementation Will be discussed in greater detail in ISSL. Kathie: what problem does it solve? [Answer supplied after the meeting: It's a way to implement various functions that have traditionally required per-microflow state in a diffserv-like environment, should that be useful.] Raj Jain, effect of number of drop precedences in assured forwarding Simulation. Find in terms of producing fairness between TCP and UDP (the stated reason for having 3 instead of 2), 3 drop precedences is no better than 2 drop precedences, even when change the token bucket parameters. True for either single-rate or two-rate. So two gets you far from one, but three is just wasted work. Reason: TCP does not distinguish between loss of packets of different drop precedences. There are two dimensions to work with, drop precedence and class (bandwidth). DP is more random - whether you can "get into the room" depends on when you arrive at the room. Use class as a much finer control on discrimination. Curtis Villamizar: query on different rates on the meters. Raj will do a simulation of Curtis's preferred configuration. Juha Heinanen: Juha's idea is that if he has a customer who doesn't slow down when packets get dropped, his packets would be marked red more often than some customer who does slow down when he gets dropped. Raj: when you do simulation there are four ratholes. One of them is the wrong configuration. Raj will continue working with Juha to get what he had in mind.