Meeting minutes for the DiffServ WG meetings in Adelaide, AU Co-chairs: Brian Carpenter and Kathie Nichols Reporter: Walter Weiss Brian Carpenter (for David Black) presented a draft for Tunnels with DiffServ. Changes from previous draft. This version is shorter. It also recommended that tunnels be able to require that exiting traffic undergo diffserv traffic conditioning. There was also significant cleanup of the text. The tunnel egress node has to decide whether to use the inner or outer codepoint. There was an earlier proposal to use DSCP 0 as an indicator of whether to use the inner or outer codepoint value. The conclusion was that this was the wrong approach and that this choice should be determined through configuration of the egress node. Additional issue: Suitably configured/provisioned VPN tunnel makes ingress and egress nodes "virtually contiguous". Currently this concept is described using the term "same diffserv domain" but this may not be the right phrase. This should not require an RFC update because RFC 2475 requires that the ingress and egress be in the same domain. An additional question was whether to add a list of tunnel types. Tunnels are discussed in numerous RFCs including IPSEC and NGTRANS. Should references to these various RFCs be included in David's draft? This will take a while and involve other WGs. Current text does not update EF RFC to eliminate EF requirement in outer header, should it? John Wroclawski pointed out that this was not unique to EF. This will be input to eventual revision of RFC 2475. Brian asked whether this draft should be a standards track or informational. Juha suggested that this work should be considered in a larger context (MPLS). John W. argued that if the draft is informational, the SHOULDs and REQUIREDs need to be removed. Fred suggested that the choice of egress header determination is sufficient as a sentence in a future rev of the header document. Joel thought that this clarification is deserving of a RFC because there was confusion on the topic. Someone mentioned that the MPLS folks are referring to this document. Juha thought that the document should be generalized beyond specifically specifying IP. He would prefer to see a draft describing the mappings of DSCPs in generic tunnels. General consensus was that this document could be moved on an informational RFC track with appropriate adjustments and support from the TSV area directors. Andrew Smith discussed the alignment of the conceptual model with the MIB and the PIB. Some issues relate to terminology (discarder vs. dropper). There are also some structural issues that are being worked. Andrew is suggesting that many of the inconsistent concepts need to be moved from the MIB to the model. There are a number of open issues: 1. There is a difference in interpretation of the token bucket behavior between the model and the MIB. Kathie indicated that the problem was that one description allows a packet to be sent when there are some tokens but not enough for the full packet size while the other description only allows a packet to be sent when there are enough packets for the full packet. Fred implemented the partial token approach in the MIB to cover the case where the bucket size was smaller than the packet size. Fred also pointed out that his description was of a meter (ingress) while Kathie was talking about a shaper (egress). Kathie and John W. wanted to define the conservative definition (requiring a token value greater than the packet size). Kathie indicated that she wanted the model (as opposed to the MIB) to be more conservative. There was agreement to continue this on the mailing list. 2. Should a classifier be part of a TCB? Model assumes yes while the MIB assumes no. Andrew will make the model align with the MIB. 3. Should MPLS be discussed in either document? General discussion suggested that less focus should be given to MPLS. 4. Should the model include discussion of non-DSCP markers? Loosen wording in the model document to allow other markers (802.1, or labels). Because the MIB is specific to DiffServ, the MIB document should not be loosened. 5. The meter in [SRTCM] cannot be precisely modeled using two two-parameter token buckets because its two buckets do not accumulate credits independently. Do we need to show how the [TRTCM] meter should be implemented? There was no time to discuss this. 6. Are the current examples for queues, scheduling and buffer management sufficient? Kathie stated that as these are still areas of research and that we ought to be less precise about specifying particular algorithms. 7. Is the description of a shaper sufficient? Andrew would like additional comments on section 7.2. Juha suggested that there are some boxes that can shape both on the ingress and the egress. A number of people agreed and Andrew said he would clarify the text. 8. Does the concept of a Queue Set belong in the model (and the MIB). Dan Grossman would prefer to see the Queue Set concept removed. Andrew believes that Queue Sets allow information to be shared between queues such as shared buffering. DiffServ MIB Open Issues (Andrew) Breakdown of objects into: core, optional and "no way". Each attribute needs to be evaluated to determine its status. There needs to be agreement on conformance statements. Closer alignment with the Conceptual Model is also an issue: 0. One example is difference in terminology (discarder vs. dropper). Brian would like to see the two converge. The justification for the difference in terminology is that the organization of the components is different between the MIB and the model. The dropper was for AF traffic that does not conform. A discarder drops all packets. Yoram suggested that this was a special case of a dropper. John W. wanted to name everything a dropper (absolute and algorithmic). Dan Grossman stated that the introduction of the term 'discarder' was unintentional, and that it would be appropriate to use dropper to align with RFC 2475. Another terminology item was 'counter' vs. 'monitor'. John W. noted that "a monitor is a lizard". Consensus was that all references should be to counters. 1. Cascaded token-buckets are not equivalent to a multi-rate token-bucket: do we need to fix this by allowing a multi-rate TB in the MIB or by defining cascaded buckets to mean "multi-rate"? John W. believes they are not the same thing. Fred and Andrew will discuss this further. 2. Markers were resolved earlier in the discussion where it was agreed that the MIB would only define DSCP markers. 3. Counters: be part of various modules (dropping, scheduling, etc.) or should a separate monitor block be specified. This issue was not given any discussion time. 4. Queue Sets: already discussed previously. 5. Do we need scheduling units of 'packets' (as opposed to KBPS or BPS)? Not discussed. 6. Are absolute rates sufficient or should we include "relative to line speed" ones as well? Not discussed. 7. Scheduler parameters defined in weights vs. rates vs. priorities: the proposed text is confusing. Andrew wanted to use only rates and priorities. Not discussed in the meeting. DiffServ PIB Issues (Michael Fine) Michael reviewed the benefits of the PIB. He then discussed the need for 'roles'. There are 4 fundamental PIB elements: Interface Types/Capabilities, Filters/Classifiers, Meters/Actions, and Queues/Thresholds. There are Capability Policy Rule Classes for specifying the capabilities of classification, policing, and scheduling components in devices. Joel was concerned that the classification was too implementation specific and inconsistent with the conceptual model. This discussion was not concluded and will be moved to the list. (second session) Brian noted that folks were confused about why behavior aggregate work was part of the charter, even though this was agreed to in December. Kathie presented an overview of the BA draft. The intent of the BA draft is to expand on the BA definition that has been used loosely in DiffServ to date. Another desire was to put in place a process for defining generally useful BAs. Kathie wanted to have the group consider whether these BA documents should be experimental or informational RFCs. A BA should define what Traffic Conditioning is used and how per-hop-behaviors should be specified. Juha questioned the need for this work. Kathie argued that BA definition was a useful step toward defining services and that particular BA defnitions were not required of network operators. Van provided a review of the virtual wire BA draft. The purpose of the VW BA is to support circuit-oriented traffic over an IP backbone. The jitter window for any packet in the VW BA is a function of the time slots in the circuit switched network at the egress of the IP network. Therefore, higher link speeds in the IP network will allow larger jitter windows at the egress of the IP network. This additional jitter window allows the order of packet processing due to collisions between different customer packets within the same BA to be immaterial to the service. Dan Grossman was very confused by the draft, and its implication on the existing definition of BAs, what the topological scope of a BA was presumed to be, whether a BA was intended to be a type or an instance, and in general how this draft related to the existing diffserv architecture. Scott Brim believes that BAs are a good thing to do, but he agrees with Dan that the BA doc is poorly specified. Fred asked whether the BA specification are to be used to help construct domain specific services. Kathie indicated that this was the intent of these drafts. This discussion will continue on the list. Kwok presented current changes to the MIB. With the limitation of less than 5 minutes of presentation time, Kwok spent most of this time on the major change areas of the more flexible Action Table, Queue Set and Queue Tables. With the dropper as one of the Action Types, relating to the Queues, Kwok presented a specific random drop model. With the flexible Action Table, many different random drop models can be supported by the current MIB, not just one vendor's or just another vendor's. Current rough consensus is to keep the Working Group MIB as flexible to accommodate any vendor's random drop model as done in the version 02 draft, and remove any vendor's random drop model from the Working Group MIB. The terminology of random drop and where it is specified may be changed to align with the Model draft. Van commented that a dropper curve should not be specified. Van also believes the parameters proposed in the Firiou and Borden paper referenced by Kwok will result in a poorly functioning RED.