[Diffserv] Minutes from DC

Diffserv Working Group meeting, Wahington D.C.

Chairs: Brian Carpenter and Kathie Nichols
Reporter: David Black

----- Monday Evening Session, November 8, 1999 -----

-- Agenda Bashing and WG status

Core WG drafts today.  Tomorrow will take up unsolicited drafts.

-- New Terminology - Dan Grossman, Motorola
        (draft-ietf-diffserv-new-terms-01.txt)

This document's purpose is to capture group decisions on terminology and
taxonomy
        for use in future documents.  Summary of these changes:

(1) Use the terms Service Level Specification and Traffic Conditioning
Specification, not
        Agreements (latter implies business contracts).
(2) The definition of PHB Group in RFC 2475 doesn't fit the entire set
of AF classes.
        Hence, AF is a type of PHB Group.  AF1x, AF2x, AF3x, and AF4x
are instances of
this
        type, only the instances are PHB Groups.  The next update of RFC
2597 will reflect
this.
(3) The DS Field is no longer the entire TOS octet.  DS Field is the 6
MSBs of the
(former)
        IPv4 TOS Octet and IPv6 Traffic Class octet.  The other two bits
are currently
        unused by diffserv.  DSCP is a value in the DS Field.
draft-bradner-iana-allocation-02.txt
        (soon to be an RFC) is an example of this usage.
(4) MPLS needs notion of a set of Behavior Aggregates with a common
ordering constraint.
        Terms: PHB Scheduling Class = PHB group that has a common
ordering constraint
        Ordered Aggregate = Set of Behavior Aggregates that share an
ordering constraint.
        The words "All of the packets of an OA are members of the same
PHB scheduling
class."
        are problematic due to the use of "members of".  Francois Le
Faucheur has provided
        an alternative: "An Ordered Aggregate is the set of Behavior
Aggregates that
correspond to
        the PHBs of a PHB Scheduling Class".  This will be incorporated
into the draft.
The terms in (4) are actually applicable to any device that polices an
edge interface,
MPLS just happened to encounter the need for these terms first, but
they're not specific
to MPLS

Reference [3] in the draft (RFC 2597) needs to be corrected.

An issue was raised that an ordering constraint affects packets within
the same microflow;
not reordering the Ordered Aggregate is sufficient to achieve this
property, but not
necessary.
On the other hand working involving the term microflow seems to be a bit
strong to put in
a core
diffserv document.  The next version of document will have a parenthesis
around the word
microflow
to reopen this issue.

All other issues in this document are considered to be closed.

-- PHB ID Draft - Scott Brim, Newbridge
        (draft-ietf-diffserv-phbid-00.txt)

This is a minor update to the PHB ID draft (draft-brim-...) from Oslo.
This is a teneral purpose approach to signal PHBs (as opposed to DSCPs).
Have added a flag to indicate whether PHBID is a single PHB or a set
(Bit 14).
Sets are as defined in the appropriate document, for unusual sets (e.g.,
2
        of the 3 AF 1x PHBs), a list of the PHBs should be signalled.
Also added a few examples.
Standard PHBs use recommended DSCP, otherwise IANA allocates a 12 bit ID
value.
        Bit 15 is set to 1 to indicate latter case.

Next step is to last call this on the mailing list.  No opposition to
this in the meeting.

-- A Conceptual Model for Diffserv Routers - Brian Carpenter, WG
co-chair
        (draft-ietf-diffserv-model-01.txt)

The authors are Yoram Bernet, Andrew Smith, and Steve Blake, but Brian
is presenting due
        to absence of Andrew and Steve

Changes since previous draft:
        - New Glossary
        - Allow all model elements to be associated with both ingress
and egress
interfaces
        - Queues are first class elements in the model
        - Routing core function characterized: zero loss/zero delay in
conceptual model
                Actual loss/delay gets reflected in traffic conditioning
elements of
conceptual
                model.
        - MPLS LSRs acting as Diffserv routers: discussion added,
although the DS Field
                is hidden from an MPLS router.  This creates some
complications.
        - Meters are now separate with more discussion of simple and
multi-bucket meters.
                Appendix A contains a concrete definition of a token
bucket.
        - Mux, mirror, enqueue, and null action elements added.
A mirror makes a logical copy not a physical one, mirror may need to be
replaced with
        another word as part of clarifying text, "tee" is one possible
replacement,
        "inverse mux" is another, "splitter" is a third.  Both of these
changes need
        to be made to the text.
        - Lots of details added on queue parameters and queue sets. 
Shaping queue
                also defined.
Removal of items from a queue is not modelled well.  Queues can be
thought of as
having both a buffering element and a scheduling discipline that can be
considered
separately.  Dan Grossman will send some suggested language to the list.
        - Traffic conditioning blocks can be composed of any elements
connected in any
                fashion, and TCBs are recursive, and hence can be
connected with TCBs
                and other elements to form yet other TCBs.
        - TCBs have 1 input and one output:
This is an oversight and will be removed in the next version (e.g.,
Figure 8 is a TCB
with one input and multiple outputs).

The overall motivation for modelling queues is to have enough detail to
be able to push
rules down to routers - need enough details of how the queue works to
write these rules
in a standard fashion, but don't want to specify every last
implementatation detail.

A discussion ensued about specific queue parameters, such as minimum
service rate.
The motivation for what was done is that min and max rate are reasonably
generic,
and going beyond there gets into implementation-specific details very
quickly.
These are supposed to be primitive elements (e.g., could model a complex
implementation
queue as being logically composed of multiple primitive queues in the
model).

Overall caution - this is not supposed to be a prescription for hardware
designers.

        - New section on security considerations.
        - Appendix A is a new example.

Open Issues ...
- Appendix A token bucket definition is fine as is.
- SRTCM meter cannot be built out of a set of that sort of token
buckets.  This
is an important example as it's very close to Cisco CAR.  The meters in
this
draft are examples, but need to check MIB to make sure that this meter
can be
modelled adequately there.  Pointing to description of this meter in the
AF
RFC is an alternative to describing it here, as the cascading token
buckets
example is easier to describe.

Comment: Put some restrictions on the composition rules to avoid
ridiculous things.

Monitoring elements will be generalized to count without an indication
of
        direction so that a monitor can track queue size. 
Discussion of specific resolution text will have to be on the list where
all the 
        authors can participate.

- Should traffic conditioner blocks be allowed to contain classifiers?
        Seems to be an ok thing to do given how definition of a TCB has
evolved,
        but will not be changed to allow this, as there was no
compelling reason to do so.
[note from kmn: this TCB is not to be confused with the definition of
"traffic
conditioners" in rfcs 2474&2475. Those explicitly do not include
classifiers.]

- RSVP module: discussed on list, RSVP is only an example, hence the
module needs
        a more generic name.  Functionality is to handle QoS information
that is
dynamically
        signalled, potentially on a relatively fine grain.  MPLS LSP
setup protocol can
        also be used as an example here.

Comment: Cable Device MIB has a large amount of policy extensibility,
based on classifying
        packets to an arbitrary number that then has its own set of
tables.

- Should MPLS LSRs be mentioned in the model?  Yes, MPLS classifiers are
an important
        part of a router implementation.

- Do class selectors require additional queue parameters?  No comments
in meeting.

Open issues, especially queue issues need to be taken to list for
resolution.

-- Diffserv MIB - Kwok Ho Chan, Nortel
        (draft-ietf-diffserv-mib-01.txt)

MIB draft didn't quite make cutoff, but really needs to be discussed.

Added Andrew Smith's IP 6-tuple MF classifier.
Added info on where the classifier configuration information came from.

The latter precipitated a long discussion on whether a more generic
approach
to indicating the source of arbitrary information, not just classifier
configuration information was in order.  No clear resolution, as much
of the room did not understand the issues well enough to express an
opinion.  This is complicated by the forthcoming PIB discussion in
the OPS configuration management BOF, and hence the whole matter has
been taken under advisement by the MIB draft authors.

The queueing text has been clarified to allow multiple queues/scheduling
        disciplines to be used on the same interface.
Discussion on the list determined that the Meter Pass and Meter Fail
objects
        should be allowed to point to anything - the draft will be
updated to
        reflect this.

Queueing issues came up here again.  Andrew Smith is expected to provide
some text on the use of minimum and maximum rates.  Subclassing to add
additional queue parameters was mentioned as a possible structure.  Van
Jacobson will send a detailed proposals to the list on:
        - This subclassing approach to queues
        - A more general approach to configuring token buckets.
        - Changing the meter specification so that the count can never
be negative.

Next version will add a table to specify an interface role.  This is a
policy
        WG concept that makes higher level provisioning easier to do.

Final addition is that the MIB draft needs a diagram and usage section
to clarify
        relationship of tables, how they are intended to be used, and
how this relates
        to the model.

Still have work to do on this document -- there are issues to be taken
to the list.
        May need an interim meeting to make progress faster than the
list has been,
        but should try email on list first.

-- Diffserv and Tunnels - David Black, EMC

Your intrepid scribe presented this, hence all I can do is refer to the
draft.

Two conclusions:
        (1) The final slide of the presentation raised open issues. 
This will
                be taken to the list for discussion before preparing a
new version.
        (2) WG consensus is that this is important, and the next version
of this
                draft should be a WG draft (i.e., draft-ietf-diffserv-
...).

-- Closing Remarks, Kathie Nichols, WG co-chair

Would like to focus on issues that need to be resolved to encourage
diffserv deployment.

----- Tuesday Afternoon Session, November 9, 1999 -----

This is the unsolicited draft session.  These notes capture the brief
resolution
of what to do with each of the unsolicited drafts, as well as salient
points that
were discussed.

-- SNMP-based QoS Programming Interface MIB for Routers
        (draft-kanada-diffserv-qospifmib-00.txt)

Portions of this draft are candidates to be merged into the diffserv
MIB, especially
the classifier objects.  The authors of this draft need to take this up
with the
MIB draft authors, and additional suggestions for things to merge should
be sent
to the list.

-- Rate Adaptive Shapers (draft-bonaventure-diffserv-rashaper-01.txt)

This should be discussed on the list and then may be advanced as an
Informational
        RFC as complement to RFC 2697 and 2698 if the WG approves via
the list.

-- draft-bless-diffserv-multicast-00.txt

Multicast issues need to be taken up at some point, but WG has other
more pressing
matters that need to be attended to first.  This draft is primarily
about how to
add diffserv to multicast routing, and is proposed as material to
incorporate
into the diffserv architecture RFC (2475).  Needs extensive WG
discussion in order
to revise RFC 2575 (Section 5).

Provisioning material should be taken up with Traffic Engineering WG,
not here.

There's also some issll WG work on a multicast branch in the middle of a
diffserv
        network in the intserv over diffserv work.

Need to make sure that the scope is clear before taking up as WG work
item,
        but problem area is important to address.

-- draft-bless-diffserv-lbe-phb-00.txt

Less than Best Effort PHB.  Part of the proposed solution to multicast
problems
identified in previous draft.  Also useful for background data, penalty
boxed flows,
and deploying multimedia apps in a way that won't disrupt existing
traffic.

Significant discussion occurred both in the meeting and on the list
about whether
a new PHB is necessary.  The WG needs to address this set of problems,
but the need
for a new PHB is an open issue that will be taken to the list.  If a new
PHB is
needed, then it can be decided whether this is the right base document
to start from.

One proposal was to remap DSCP 0 to be the same as Class Selector 2,
thus turning
Class Selector 1 into LBE.

-- Time Sliding Window Three Color Marker
(draft-fang-diffserv-tc-tswtcm-00.txt)

This is a TCP-friendly marker that works better than token bucket for
TCP running
through RIO-like droppers.  Comes in 2 and 3 color versions.  There are
experimental
results that will be reported in Broadcom '99 (December).

The experimental results should be made available to the WG, and then it
would be
reasonable to have this draft progress to become an experimental RFC. 
The authors
will post a message to the list containing URLs for all of their
results.

The diffserv WG is not currently progressing traffic conditioning
documents as
        standards track RFCs.

-- draft-fu-diffserv-security-00.txt

Despite none of the the authors of this draft being at the session,
comments were
made that the draft has some merit because it looks at problems caused
by boundaries
not working correctly - diffserv assumes that edges do work correctly
and interior
nodes depend on this.  Looking at what happens when this assumption is
accidentially
or deliberately false is of interest, although this draft is at best
very preliminary,
and in particular needs to have the configuration protocol material
removed and 
taken up with the appropriate protocol WGs.

-- draft-lin-diffserv-gtc-00.txt

The authors of this draft were not present and did not provide any
presentation
material, and hence the draft was not discussed.  If they would like the
WG
to do something with this draft, send the request to the list.

-- draft-nadas-diffserv-experience-01.txt

Update of a previous draft presented at the Oslo decides BOF.  This is
primarily
to provide information to the WG, atlhough an Informational RFC is not
the best
way to publish this sort of results.  The WG thanks the authors for
their efforts
in making their results available as an Internet-Draft, and encourages
others
with similar results to do likewise.

-- Expedited Forwarding with Dropping PHB
        (draft-dieder-diffserv-phb-efd-00.txt)

EF for wireless to deal with peculiarities in that domain.  Wireless
will always drop
        packets under some circumstances.  The proposed PHB eliminates
congestion
        drops, but allows drops caused by media effects in wireless. 
This PHB may
        also be useful for fixed networks, to absorb otherwise unused EF
capacity.

[kmn: I explicitly noted in the meeting that this proposes a different
PHB than
the PHB called EF in RFC 2598.]

Needs more discussion on list to decide whether to advance this as a
standards track
        document, experimental document, or not at all.

-- The Multimedia Color Marker (draft-medina-mmcm-00.txt)

Adaptive color marker for audio/video streams.  Modification to Juha
Heinanen's three
        color marker.  Adds 3rd Token bucket to limit inbound traffic
and drop proactively
        on ingress rather than reactively when problems occur.
Goal is to increase delivery probability of green packets by dropping
yellow/red at
        edge node that knows the difference as opposed to somewhere
inside.

An opinion was expressed that marker documents should not also discuss
dropping.

The draft needs more feedback, and support from group.  Relationship to
the existing
        informational marker RFCs (2697 and 2698) is particularly
important to discuss
        on the list.

-- Interoperability PHB group
(draft-kilkki-diffser-interoperability-00.txt)

This draft reraises a proposal to define PHBs that can be used
end-to-end rather
than edge-to-edge within a domain.  This idea was rejected by the WG
almost a
year and a half ago at the Cambridge, MA interim meeting, due to
opposition from
major ISPs.

Representatives of two medium sized network operators opposed
consideration of
this material here, with one suggesting that the general topic of
inter-ISP
service interoperability belonged in an ISP industry forum, not the
IETF.

-- End of Meeting Comments

Overall, the areas that seem to be of strong interest are: Multicast
issues,
        Less than Best Effort PHB, and EF with dropping PHB. The merits
of
	the approaches proposed at the meeting weren't clear though. 

Diffserv over specific link layers (primarily PHBs) should be done via
changes to the
        issll WG charter, not in the diffserv WG.

A comment was made that the diffserv WG needs to start discussion of
services to avoid
to avoid inventing new PHBs for services that can be implemented by
appropriate
configuration of existing PHBs.

More discussion on these topics to come on the list.

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/