Last Modified: 2004-10-15
| Done | Submit initial I-D of Requirements | |
| Done | Submit initial I-D of Framework | |
| Done | Submit initial I-D of Recommendations BCP | |
| Done | Submit Requirements I-D to IESG for publication as an Informational RFC. | |
| Done | Submit Framework I-D to IESG for publication as an Informational RFC. | |
| Dec 03 | Submit Recommendations I-D to IESG for publication as a BCP. |
| RFC | Status | Title |
|---|---|---|
| RFC3487 | I | Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) |
| RFC3523 | I | Internet Emergency Preparedness (IEPREP)Telephony Topology Terminology |
| RFC3689 | I | General Requirements for Emergency Telecommunication Service |
| RFC3690 | I | IP Telephony Requirements for Emergency Telecommunication Service |
|
---------
IEPREP - November 9, 2004 - 15:45-16:45 EST Notes taken by Aaron Falk Agenda: - welcome - chairs - MLPP in IP networks - reading list: draft-silverman-tsvwg-mlefphb-01.txt draft-baker-tsvwg-mlef-concerns-02.txt draft-baker-tsvwg-mlpp-that-works-02.txt Scott: primary work today is to decide whether to proceed with the above drafts. Multi-Level Expedited Forwarding: Steve Silverman (draft-silverman-tsvwg-mlefphb-01.txt) Background: Sometimes there is insufficient bandwidth on a network. DOD and some other agencies need to prioritize users in those cases. This is done with five levels, the traffic on each level is normally less than 10% of the next lower level. Session control, e.g., Call Admission Control (CAC), is needed but may be of limited value since Silence Suppression may be in use (which can cause short term congestion). MLEF Overview: This is a simple cross between AF and EF. It uses a single queue with EF behavior and with multiple discard probabilities like AF. MLEF uses DiffServ with separate DiffServ codepoints for each class, but still one queue. As packets are queued, the classes are checked. Implementation: MLEF has been tested. It works with the high priority traffic getting through. It turned out to be easy to implement. We would like to get this approved as an experimental RFC. Q&A: Chris Christou: What mechanism provides the ability to clear out the LP traffic in favor of the HP traffic? Steve: New packets get dropped at the bottleneck. Preemption may be used in the future to allow CAC to stop sessions, but not yet sure how this would work. However, at this time, the LP source is still sending. Sridam from NIST: Are different priorities in the same or different applications? Steve: All users are one of five priorities. I.e., the president never gets a busy signal. ??, BT: How do you get prioritized for HP traffic? By endpoint or session? Steve: On our closed military network, each user has a physical card which is used to authorize a user (common access code) and gets plugged into the phone. All of the users' traffic (voice only) gets the HP treatment. There is other non-voice traffic in the network. Scott: We need to be concerned about using this on non-military networks which may not use CAC. Pradeep, Lockheed: If all calls have CAC, how do you get overloaded? Steve: Id you assume you are using silence suppression and the network is fully loaded, then everyone says "wow" at the same time you'll get a momentary overload. MLEF results in the captain getting to continue his call. Pradeep: Does the DSCP identify the user? Steve: No, just which of the five or six precedence levels. ??: are you mixing voice with other traffic? Steve: The way EF works is that you configure a line to give EF a certain bandwidth. The other traffic gets the rest. Dennis Berg: In a circuit switch world, all the 5's get knocked out before impacting any 4's. Is this true for MLEF? Steve: yes. ??: Did you measure degradation as opposed to loss? Steve: We evaluated based on subjective impressions of voice quality. Fred Baker I have some slides but may not use them. My comments only apply to voice. Notice on this slide Flash Override, Override, and Routine: three levels of precedence Here's another approach which uses 11 levels of precedence. Watch this demo from CORVIL. Tool simulates an MPEG-4 datastream going by and shows queue lengths as packets arrive and depart as measured by MRTG. Notice as the number of flows goes up, the additional capacity needed to meet an SLA reduces (in ratio to the total capacity needed). (http://www.corvil.com) My concern is: under any circumstance where MLEF accomplishes something, it destroys an entire class of traffic. In video, it obliterates the entire screen, i.e., everything you've got going on. The idea is that one application shuts down and another will step in. The reality is that the old application will continue to send, and the new one will compete effectively. If you want the good one to get through, there is a different approach which I am nearly done writing a draft for, on elastic traffic. The mlef-concerns document describes why the telephony approach doesn't apply to IP networks. In the PSTN, there's nothing in the call itself which describes the precedence of the call, it's all in the control plane. Same for an ATM network. In the IP network, the principal difference is that our routing is done differently, even though it is just as deterministic as for ATM. So, the question becomes: if you don't need a DSCP in ATM or TDM, why do you need it in IP? Why does CAC suddenly not work? What you want is "path aware" and "loading aware" CAC that will allow us to decide whether to bring in a new call. Typically, we don't do bandwidth-aware CAC for VOIP. We do domain aware CAC which knows something about rules on how many calls are going on in the domain. But this is unaware of the routing of the call. The control path and the data path may be radically different. For the military network, you really need to know the routing of the data plane. In EF you run your network lightly loaded. For MLEF to accomplish anything, you need a queue. This adds latency, and delay variation. Steve: This has to do more with how you choose your packet limits. Joe Zebarth: What is your definition of significant latency? Fred: In our experiment it was 40 voice packets deep. Mary Lynch: Is the algorithm in hardware or software? Is it 'easy' to implement? Fred: yes (either): and its easy to implement. It drops based on thresholds. Similar to RED in behavior. The question is whether the algorithm accomplishes the right thing. Chris C: How do you configure your network? (to Steve) Steve: If you configure your network to configure a certain percentage of voice traffic, you can set sufficient amount. ??: With dynamic VPNs, you can apply different solutions. These can apply CAC within the VPN with the VPN meeting bandwidth limits. Fred: That is interesting but orthogonal to the problem at hand. Scott: Today's goal is to decide whether the ieprep WG recommends to the tsvw that the two docs on the agenda move forward. Fred: (responding to question from Dr. McGregor) Cisco is seeing, in some environments, that CAC is completely out of the picture. I don't think this will work. There needs to be an effective CAC and it needs to be aware of current routing. So what do I suggest? Fifteen years ago the Bob Braden and the IETF finished the first draft of the technology that solves this problem: RSVP. I propose this as the solution for the data path. You still need the SIP protocol to set up the session. You may need to express priority to the end system, too. This is another class of problem. You also may apply some policies, such as in Navy NCS network. NSIS doesn't at this time have the features that are needed for, e.g., preemption. So it is not a viable candidate today. If it did have these features, it might be a better candidate Scott: How many have read the drafts? - (About 1/4 the room.) How many of you think you understand Steve's proposal enough to express an opinion? (About 1/3 of the room.) Steve's proposal is qualified to apply only to a 'private, closed' networks. (I don't believe this is always going to hold.) The question of whether the IETF should standardize behavior in private networks has been under discussion for a long time but that aside should we tell tsvwg that Steve's proposal should be worked on? (Half of those knowledgeable, or 1/6th of the room) On Fred's proposal: How many of you have read Fred's document or understand its contents? (About 1/3 of the room.) How many of you think that we should tell tsvwg that we think they should work on that document? (About the same number supported this as answered yes to the last question.) |