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.