Editor's note: These minutes have not been edited.
Minutes of the INTSERV WG meetings held March 5th, 1996. (These minutes do not cover the joint INTSERV/RSVP/IPATM/ROLC meeting held March 6th, 1996).
TUESDAY AFTERNOON MEETING
This meeting was devoted to new topics in INT SERV.
INT SERV MIB PROGRESS REPORT - Fred Baker
JJ (John Krawczyk) and Fred have developed a MIB (6 objects). Key issue is how to divide INT SERV information with RSVP and ST-II information. MIB just tells you information about interface properties (what link capacity, etc). Stuff in RSVP and ST-II MIBs tells you how the capacity is allocated.
By interface, you can.....
* configure total bit rate that can be allocated
* configure max bit rate for any one flow
* display currently allocated bandwidth
* current delay being experience by traffic (has been deleted)
* add display parameter indicating bit rate allocated per service
* currently allocated buffer is in the MIB (sum of burst sizes)
Fred expressed interest in getting this MIB done soon, so please send him suggested objects.
INT SERV DATA OBJECTS - John Wroclawski
Internet-draft (draft-int-serv-data-formats-00.txt) describes some requirements and a data format for I-S data objects within protocol messages. RSPECS & TSPECS, etc.
John presented a data object library:
- Treats I-S data as opaque to setup protocol or similar - Supports:
- creation and deletion of objects
- ordered set of per-service information fields within each object (ordered so RSpec, etc can express priority of different services in request.
- Addition and deletion of service-specific info from the set. - Listing of which service-specific parameters are actually present for each service.
- Creation, modification, and deletion of the parameters given for each service.
- Some simple error handling and checking (e.g., that IEEE floating-point numbers are valid.)
SERVICE DISCRIMINATION FOR BEST-EFFORT TRAFFIC - Dave Clark
David Clark gave a talk on the topic of explicit allocation of best effort traffic. This represents a somewhat new topic for the integrated services working group. The initial goal for INT SERV was to add support for new services like voice and video. But discussions on the mailing lists have shown that there is also a need to give the ability to control best-effort quality of service too. This talk described one possible way to provide multiple levels of best-effort traffic service.
The goal of the enhancement proposed by Clark was to allow different users to be explicitly allocated different capacity service during times of congestions. Capacity need not be measured using a simple model such as a fixed minimun rate, but could be characterized in a broad range of ways, which could model traffic with different degrees of burstiness at different time frames. The approach was to provide each user with a usage profile, and tag traffic entering the network as to whether it is in or out of this profile. At any point of congestion, the router preferentially discards packets marked as being out of profile. The result of this discard is that the sending TCP perceives an indication of congestion and slows down. It will continue this process until all of its packets are marked as in profile. At that point, different TCPs may be getting very different services, depending on what their profiles are.
The talk presented two schemes, one driven by controls at the sender, and one by controls at the receiver. It also included some initial simulations to suggest that somewhat accurate control on usage was actually possible.
This talk reported ongoing work, not material being proposed for standarization at this time.INSERT DAVE'S TALK
QUESTIONS: How complex are profiles? Dave says quite complex.
Juha - Doesn't profile scheme depend on source and destination profiles? DDC notes that yes, if you've got a big profile but the destination has small pipe, you won't get full throughput. Matter of education (folks need to be aware of Internet heterogeneity).
Floor: Suggest moving profile out to the hosts (some hosts are big pigs, or some folks in corporation have different profiles -- CEO vs. others). DDC says he agrees.
Floor: Does IP ToS field on WFQ give similar service? DDC not quite (difference between precedence and in/out bits).
Floor: Question regarding pricing scheme. If ISPs are only charging during congestion, doesn't that give them motivation to be congested? DDC -- currently ISPs charge you for capacity (or modem hours). ISPs currently have this conundrum that there's no motivation to add capacity except fear that competitor has better capacity and will attract one's user. And if one looks at congestion portion of fee, it is pretty small -- and note that expectation scheme means we actually don't charge during congestion (we charge for a promise you won't be congested).
Greg Minshall: How does in/out marking work at multiple check points (MIT, NEARNET, MCI all check)? DDC's idea is that this is fine, and that one can mark packets at out at multiple spots (and indeed, ISPs can observe traffic marked in by MIT that the ISP needed to mark out and suggest to MIT that they increase their expectation).
Abel Weinrib: If someone gave me TurboTCP that didn't back off. Doesn't this fall apart? DDC, says if we are overloaded, in packets still get through, and outs gets nailed (and trying to be greedy just ensures you get marked out).
Points out world is more than just point-to-point link and ATM links.
Frame-Switched media problems. LAN switches do simple fifo, frame relay has no delay characterizations.
Current work, IEEE 802.1p (signalling via management and GARP -- no admission control or policing -- just destination and source MACs and priority scheduling)
Proposes that we do some work on implementing services (how-to guide with current technologies and discussion of adaptation protocols that we use over layer 2 protocols).
Question -- are vendors thinking about adding guarantees in MAC switches (Ethernet)? Fred Baker points out that MAC switches sell not on features but cost per port, so guarantees better be very very cheap to include.
DON HOFFMAN AND RAJ YAVATKAR -- Mother May I protocol for Level 2. Services that does admission control for 802.3.
Don, protocol he's developed using softstate and reservation messages (MMIP). Multicast protocol used to find subnet bandwidth manager, and unicast protocol to talk to the manager (Mother). No enforcement (but some policing at hosts, who cooperate).
Raj Yavatkar is writing a spec for the protocol.
MINUTES OF THE TUESDAY EVENING MEETING
There were four items on the agenda: Discussion of the Guaranteed Service (G) specification ID. Discussion of the Controlled Load (CL) specification ID. Presentation on the Protected Best Effort Service. Presentation on the issue of dealing with heterogeneity of QoS service offering within the Internet.
The major objective of the evening was to reach resolution on the G and CD specs.
Craig Partridge presented the material on the G ID. At the last meeting, the sense was that the ID could go forward as a proposed standard once a specific set of issues were resolved. After the last meeting, Roch Guerin revised the spec to include the new concept of the "slack term". This was circulated on the list, and no objections and some support was detected. The conclusion of this meeting was to proceed with the spec in the form that includes the slack term.
Two small issues were noted prior to the meeting: 1)The draft is ambiguous on where reshaping point are, that is, places where traffic is made to conform to a token bucket. The answer is that it is done for two purposes:
a) done to restore shape to conformant flow; OR b) force merged flows into a particular shape and perhaps discard excess traffic. The draft will be revised to make this clear. The draft does not say what to do when splitting reservations. The draft will make clear that reshaping is to be done at that point as well.
2) The draft needs to be more clear on exactly how to compute the C and D terms of the delay bound formula.
The answer is that D is precomputed when a box is configured, a property of the box, while C is more complex, computed for each flow. The draft will so indicate.
There was discussion of where to put an expanded discussion of how the delays terms is computed. The conclusion was to put the meat of discussion in an Informational RFC, but add some material to the example implementation section of the standards document, and make that document refer to the Informational RFC.
The proposed action, confirmed by the meeting, was to revise the spec to meet the above objectives, and submit it for consideration as a proposed standard. The Informational RFC would be prepared by Craig Partridge and sent to the list for comment.
There was a final point of discussion as to whether the intent of the G spec was that implementation over all media types was mandated. The answer is that implementation is only anticipated over an appropriate subset of media types used in the Internet.
Craig Partridge then chaired the next part of the meeting, in which John Wroclawski presented the status of the CL spec. He presented a prepared talk with slides, which is summarized below.
The status of the CL spec is that it was first presented in Dallas, where the sense of the meeting is that it should proceed towards proposed standard after seeing what comments arose on the net. There were in fact a few substantive isues raised between that meeting and now, which were summarized in this talk. There were three sorts of issues. 1) Some wording was unclear. These points are noted and will be fixed. 2) There was some uncertainty, or possible disagreement, about the goals of CL. The talk reviewed the issues here, but the assumption was that the goals were correct as stated. 3) There were two technical questions as to how the features of the CL specification meets those goals. The talk clarified these issues, and presented specific design choices for review.
The goals of the CL spec, by way of review: 1) Flows within profile (conforming to their proposed Tspec, should see the behavior associated with an "unloaded" network. 2) Especially in the case of multicast, the CL service and the Best Effort (BE) service must coexist. Use of CL service for a flow should not make the service worse than BE for that same flow. 3) (Not a CL goal but more a more basic service issue:) Non rate-adaptive CL flows must not be able to kill rate adaptive (TCP) traffic. This implies that a router needs to support a sharing model other than brute force wins. This point has always been around, but CL emphasizes the need to deal with it, since CL legitimizes non rate adaptive traffic.
The first technical point is whether the CL service is allowed to reorder traffic that is out of profile. Some implementation schemes reorder under overload. The following points are germane: 1) Reordering may be easier for the network element implementor. 2) Reordering is _never_ preferable for the application, since CL does not have packet selectors to control which packets get delay, and CL has no marking to show which packets have been out of profile at previous hops on the path. Thus, there is every reason to think, in a reordering scheme, that not just some but essentially all of the packets may be treated as BE and reordered by the time the traffic crosses a multihop network. However, reordering may be acceptable for one class of apps -- reordering -insensitive, like vat. There was some discussion as to the degree to which this is true. 3) There is no reason to offer both schemes. If reordering is never preferable, if implementing both, just do the better one.
Currently, the CL spec allows both reordering and non-reordering implementations of the overload behavior. This range of options was included to permit product differentiation and ease of implementation in different circumstances. The alternative that was proposed on the list was to preclude reordering implementations.
The discussion in the meeting raised the following points, positions and issues. 1) The Internet today reorders packets. Its a fact. Since Internet does reorder, leave the spec as is. 2) Reordering can hurt voice as well. But it was noted that reordering can only occur if traffic is out of profile, not in the normal case. Further, it was not clear that reordering implies a worse delay bound. 3) Due to possible distortion of traffic shape as it passes through routers, traffic that conforms to its profile at the edge may be non-conformant in the middle of the net.
After discussion of several options -- preclude reordering, or say "should not", or allow both, there was a first sense of the meeting to prefer "should not". The point was reconsidered, and the final conclusion was to put an extended discussion of the issue in the implementation discussion in the spec, and to note the benefits of not reordering in the evaluation criteria section.
The next technical issue raised was the role of the "B" parameter and its relation to buffer allocation, for both real time and TCP-style flows.
Non rate-adaptive flows such as real time can exeed their reservation for two reasons: first, multiple use of a shared reservation, and second, a transient due to burst aggregation. The minimum necessary to deal with this is a reasonable amount of buffering in the switch, but a better approach is to drop packets when the delay gets too high. One must not drop just because the traffic exceeds its Tspec, but only when actual queues develop. This queue management discipline is in fact the same as the discipline suitable for rate-adaptive flows such as TCP. Thus there is no recognized need to have two modes of buffer management in CL, for flows whose rate can or cannot adapt. Adding two explicit modes raised the further issue of insuring that one cannot cheat and get better service by asking for the "wrong" mode. So the proposal, since there is not a clear need for two modes, is not to define a means, such as the "TCP" flag, to select or specify explicit buffer management disciplines.
