[Diffserv] Draft minutes of San Diego diffserv meetings

Diffservers,

Please send any comments that you have on these minutes within a week.
They are overdue... sorry about the delay.

  Brian Carpenter
  co-chair

DRAFT

Minutes of Diffserv WG meetings, San Diego, December 2000
=========================================================

WG Chairs: Brian Carpenter, Kathie Nichols
Area Director: Scott Bradner

Monday December 11
------------------

Notes edited by Brian Carpenter from raw notes by John Wroclawski.

Kathie Nichols (co-chair) introduced the meeting by stating the chairs'
wish to reach last call on the outstanding documents as soon as
possible.

Status Updates
--------------

draft-ietf-diffserv-new-terms-03 (Dan Grossman). This is a living
document intended to capture problems with terminology etc. Not much
new this time.

New issue - what happens if unknown/improperly mapped DSCP
turns up at node and node doesn't understand? There is an
inconsistency between the generic guideline for this in
RFC 2474 and the specific rule laid down in RFC 2598, for the
case of EF traffic at a network ingress. See the new-terms
draft for the proposed rewording when 2598 is updated.

draft-ietf-diffserv-pdb-def-01 (Brian Carpenter and Kathie Nichols)

WG chairs (as authors but consulting with AD) felt discussion almost
completed in Pittsburgh, hence issued WG Last Call. This closed
after deadline of this meeting so no -02 draft public, but one is
ready to send in. Authors feel that it takes care of all comments
- editorials fixed - there seems to be rough consensus on the
substantive content. Because chairs are the authors, they
will ask area director Bradner to act as arbiter as soon as -02
draft is out - for that reason have not planned discussion today, 
but will entertain comments at the mike for a couple of minutes.

There was discussion about the procedure for new PDBs to be
approved for publication - is it too complex? Why is bar set
so high, e.g. statement of need. The authors would study any
prpoposed alternative text on this. The current intention: after 
draft published and initial discussion, an ad hoc review panel 
would be set up, requiring deployment experience
with measured results on a non-trivial network, loosely
equivalent to draft standard.

There was discussion whether simulations are acceptable. Authors
are happy to add "convincing simulations".

There was discussion whether requiring the equivalent of draft
standard is reasonable for Informational documents. Yet we should
not publish a PDB until we are sure that it really works - best 
answer might be that review panel is empowered to decide when the
evidence is strong enough. 

Also, we may be doing the wrong thing by reinventing BCP - the 
IETF has a set of criteria for BCP already. Need to check with AD.

It was stated that more guidance is needed on what the section 
on rules in PDB draft really means. Example from BH draft of overly specific rule.

Q: What if an application cannot use a current PDB? 
A: New applications might well cause creation of new PDB's?

Q: What if several PDBs suit one application, which one to use?
A: market chooses, not a WG or IETF issue.

Authors will issue draft-ietf-diffserv-pdb-def-02 and confirm
consensus.

Issue Discussions
-----------------

Model draft (draft-ietf-diffserv-model-05)

Following the Pittsburgh meeting, the major issue on the model draft 
is ensuring its consistemcy with other documents. The
MIB, PIB and Model activists held a lunch discussion today - 
Brian Carpenter believes that we will come out of mib/model
discussion with consensus on issues soon - therefore believe will proceed
to WG last call very soon - people on hook to get revisions out rapidly
after today's meeting.

There're some interactions with Policy WG - discussed below.

Interaction with SNMPCONF discussions - need a couple of new TC's in the MIB,
in separate module.  Simultaneously there will be new document in OPS to
add one TC for SNMPCONF - converge in IESG, remove redundant text in RFC editor 
step. Goal - avoid deadlock due to interdependency between docs in different 
working groups.  

QDDIM (draft-ietf-policy-qos-device-info-model-02)
(Bob Moore for the Policy Framework WG)

Document models at low level configuration of diffserv capable devices -
obvious overlap between that document, model, mib, pib documents.  

Wants input from Diffserv, but also wants to raise questions Policy WG has
in Diffserv to decide whether they might trigger changes changes to
model/mib documents.

1) location in inheritance hierarchy of schedulers
-- one model is that everything diffserv is subclass of conditioning
services
-- alternative model is that all except schedulers are "conditioning
services' but a scheduler is something different

See slides filed with Policy WG minutes.
Argument against is that scheduler sits in the control plane. This notion
got no support - it's a data path element. The diffserv model agrees:
the list of things that are in data path includes the
scheduler, and it says that scheduler can be combined into TCB.

Straw poll.  Result: Don't change the diffserv model, by large majority 
of the minority that signaled a view.

2) whether a single scheduler instance can interact with
multiple queues using different "scheduling disciplines" (ie, some priority
queues, some WRR, etc), or whether this must be represented as different
schedulers.  (see presentation picture - is configuration allowed or not)

The discussion on this was inconclusive and no change to the diffserv
model draft emerged.

3) algorithmic droppers.

Current version - head dropping and tail dropping is modeled as a subclass
of dropper service - peer to other subclasses that represent algorithms,
not location.  diffserv does this by representing head or tail dropper as
relative placement of queue element and dropper element.

- slide suggesting four independent dropper parameters
1 queue
2 where in queue
3 queues to monitor
4 algorithm

Andrew Smith proposes changing DS model to represent element 2 by position of
dropper with respect to queue.  Need to eliminate possibility of Q-D-Q
case, but otherwise makes sense.

In MIB and QDDIM there is association between dropper and queue to monitor
(how to handle more than one monitored queue?)

So, not too far from "four independent factors perspective" in MIB and
QDDIM, and informal model if we allow dropper to sit after queue implying
head dropper.

After further discussion there was consensus to accept Andrew Smith's 
proposal for relaxing restriction on droppers. Don't change scheduler-TCB 
relationship. One dropper handling multiple queues remains open question.

Brian Carpenter raised a final issue on the Diffserv model:
"Loose" vs "strict" token buckets come back many times in model
discussion. Consensus seems to be to keep current words, which allow both
but tend to favor loose. Anyone want to talk?

Three objections to the current text were raised: the two modes
should not be called loose or strict, since increase in bucket
depth makes strict TB behave as loose, and adding MTU to
burst size makes strict same as loose.  Second, no other RFC's (intserv,
TQM, etc) use "loose" token bucket. Third, although the main text allows 
both, the appendix criticises the standard TB that is used everywhere else.

Brian Carpenter: this is an informal model, informational text.  Would be
favorable to changing model document to give neutral list of issues with
both loose and strict token buckets - engineering words rather than
statement of opinion.

Shahram Davari will propose such text.

------
MIB/PIB documents (draft-ietf-diffserv-mib-06,
draft-ietf-diffserv-pib-07) (Kwok-Ho Chan)

MIB-06

Previous open issues are all believed to be reolved.

PIB-02

In sync with MIB-05. Data definition technical issues apply to both PIB,
MIB, to be resolved in MIB context - allow both documents to advance to
last call nearly simultaneously.

New MIB issues:

*** Issue: add separate DSCP counters
(pros, cons on Kwok's slide)

Open questions
- add DSCP counter table (proposal: no)
- Add counter to ClfgElementTable entry

1st question - call for opinions. none strongly in favor, no discussion.

2nd question - add counter. call for opinions, scattered support for each, no
loud noises. Proposes to go to list, wait three days for input.

Worries expressed that in some environments it would be impossible to have
counter in classifier. Thus wants counter to be optional.

Kwok - OK - pointer in table, reuse counter.

[Editor's note - this did *not* meet consensus on the list.]

*** Issue - more detail on DSCP into MIB

Proposal - add REFERENCE to DSCP RFC 2474.
The issue is that DSCP is 6 bits not a byte - many people mistake this.
Reference clears it up. Also refer to RFC2780 which gives Diffserv the 
6 bit field formally.

RFC 2474 has an obsolete (8 bit) definition of "DS field", but
correctly defines DSCP as a 6 bit value.

Resolution - change REFERENCE to 2474 and 2780.

*** Issue - hierarchical schedulers for excess BW
Current MIB does not address this.

One view - too immature to be included into a draft trying for last
call - ignore for now.
Other view - can be done in current framework by augmenting certain
parameters.

It was noted that a scheduler is like a meter with success/fail outcomes. 
Can deal with hierarchy by having fail resolution be "promotion" to another 
level of scheduler. But may need both success and failure hierarchies.

Kwok: proposes additional attribute in a SCHEDULER - two nexts - one for
success, one for failure.

Resolution - model becomes a superset of the MIB in this case - allows
mixed-action (ie, different treatment for different queues) schedulers.
MIB at present supports only single-action schedulers, will remain so.  MIB
will be changed to support both success and failure hierarchy, as above.

----

Bulk Handling Per-Domain Behavior (draft-ietf-diffserv-pdb-bh-00)
(Kathie Nichols as author) 

Broke this out of the thing that became draft-ietf-diffserv-pdb-def-01.
Not in a big hurry on this, would like discussion.

Issues and comments relevant to both BH and BestEffort PDB.

- Services are not PDBs
Examples from UUNET, PSINet service level guarantees. Real hard numbers
for delay between various points. Contrast with non-controlled nature of
best effort traffic - based on network provisioning and traffic management.

High level point is that service level performance to customer is not
directly tied to some per domain behavior - implying that PDB does not
imply a (single?  standard?  specific?)  level of performance or
provisioning.

Slide - issues from Yoram: - name: misleading.  Kathie meant bulk handling
in the USPS 3rd class mail sense, not in the large transfer sense. Kathie 
would entertain other suggestions but doesn't think Lower than Best Effort
captures the intent.

- don't want to presuppose that certain apps use certain PDB's, just make
suggestions to operators.

- other minor issues - Kathie proposes taking to list.

Tuesday December 12 - resolution of EF issue
--------------------------------------------

Notes edited by Brian Carpenter from raw notes by Joan Cucchiara,
John Schnizlein, and Martin Westhead.

Brian Carpenter chaired this session since Kathie Nichols, co-chair,
was a participant in the debate.

Agenda
------

Joel Halpern, EFResolve Design Team Report (10 min).

Bruce Davie, comment (10 min)

Van Jacobson, comment (5 min)

Discussion (25 min)

Consensus on direction to adopt (5 min)

Initial choices for consensus:

0) do nothing at this time

1) EFResolve (draft-ietf-diffserv-efresolve-00.txt)

2) EFResolve  modified/"compromise"

3) Charny et al. (draft-charny-ef-definition-01.txt)

4) 2 PHBs

Chair's introduction (Brian Carpenter)  
--------------------

The Chair thanked Joel Halpern and the EFResolve Design Team.
He was on their email list and can attest that a lot of work
went into this effort.

EFResolve design team proposal (Joel Halpern)
------------------------------

Thanks go to to the design team members:
* Grenville Armitage
* Alessio Casati
* Jon Crowcroft
* Joel Halpern
* Brijesh Kumar
* John Schnizlein

Joel stated the assignment of the design team
as fixing the problems brought before the WG, consistent with the intent
of RFC 2598. He used a diagram showing un-shaped inputs to a box with
two potential outputs: E(i) the earliest output times without competing
traffic, and D(i) the actual output times when EF PHB traffic competes
with other traffic. The essential concept intended in EF is a finite
bound on D(i) - E(i) < S * MTU/R. An output rate is implied in order
to achieve this bound. Since bursts of traffic will accumulate in a 
network that cannot be avoided, an implementation must specify how much
burst it can accommodate. All other input ports provide competing traffic.
The conformance measure the WG said it wanted is accomplished by comparing
D(i) with E(i) in laboratory experiment, not in operational network.

draft-charny-ef-definition-01.txt and proposed compromise (Bruce Davie)
---------------------------------------------------------

Bruce said EF was designed to support guaranteed rate and low jitter
in order to support (not just) virtual wire (as an example). RFC 2598
had problems identified in draft-charny-ef-definition-00.
The -01 draft was submitted for two reasons:
* its authors felt there were unresolved issues with EFResolve
* biggest complaint about draft-charny-ef-definition-00 was
that it was not intuitive, and was hard to understand.

The intuition of the RFC 2598 is that it
required EF traffic to be served a configured rate R, but had problems
with over what period R is computed, especially because packets cannot
be served before they arrive. Bruce used a diagram showing the finish
time of an output packet of length L and rate R. An ideal device would
finish output L/R seconds after it starts, and would start immediately
if there were no queue or after the queue drained otherwise. The result
was the definition for ideal departure in draft-charny:
f(j) = max (a(j), min (d, f(j-1))) + L(j)/R.
Actual departure added a fixed error term E.
A proposed compromise with EFresolve was sent to the list on December 7
to include a per-packet delay. This proposal introduced a new bound:
D(p) < B/R + E(p) to provide a delay bound with offered EF load is
bounded. The authors still have concerns about bounded bursts of EF
traffic, and concerns that E(p) "hides a multitude of sins", but believe
that this compromise is closer to the intent of RFC 2598. The complexity of 
the proposed definition is considered "just enough" to provide rate bounds.
The proposal's problem with infinite delay is fixed by its color-aware
version, and the problem with infinite buffers needs wordsmithing to
clarify. Otherwise, the authors feel they have answered all concerns
that have been raised with draft-charny-ef-definition-00. Since the 
compromise addresses both rate and delay bounds, and they still see 
open issues with EFresolve, they consider their proposal superior. 

View of RFC 2598 authors (Van Jacobson)
------------------------

Van said that the EFResolve design team captured their intent,
which was not a guaranteed rate service. He stated that
the EFResolve language was what we would have put in RFC2598 if
we'd been smart enough and wishes we had done so. His intent was 
to bound the second moment, i.e. jitter variation.

Anna and Bruce did a great job of specifying a guaranteed 
rate and that work should go forward independently.

Discussion
----------

The Chair asks that people not go too deep into the math.  
He said that he interpreted what Van said as a vote for
2 PHBs.

Question to Van:  "If EF is not guaranteed rate, why all this work 
on developing Bandwidth Brokers and not Jitter Brokers?"

A: the goal was define a PHB to support traffic aggregation into a
virtual wire service; to do this you have to bound jitter at each hop.

Anna Charny: (1) clarified that draft-charny refers to worst case 
    error, not average.
(2) we still don't know how to build a virtual wire service.
(3) the proposed "compromise" does everything EFresolve can do.
(4) we think there are still problems with EFresolve.

Anna's preference is the compromise proposed by Bruce Davie.

Jon Bennett stated that since the goal was circuit replacement, 
you need a guarantee on rate. We know how to deal with jitter
via jitter removal buffers.

The Chair noted that the WG previously expressed a clear desire 
for a measurable conformance criterion for the PHB.

Van responded that bounding the first moment gives you link 
circuit-replacement service, but bounding the second moment 
is necessary to deliver it on an aggregate.

John Wroclawski: Bruce made a more general PHB than what Van had. While
generality is often desirable, since we don't really know all the issues
we ought to make EF as simple as possible, like EFResolve, in order to 
get virtual wire to work. Different PHBs are better to accomplish different 
goals. 

Several speakers commented that the Davie compromise matches existing
expectations, products and VoIP requirements.

The Chair asked if he was correct to understand that draft-charny-...01
is off the table? That would reduce the number of possible outcomes by 
one. Bruce Davie and Anna Charney confirmed that all the authors support 
the "compromise" as described earlier.

However, Anna stated that we still don't know that we can define a PHB to
deliver virtual wire. Kathie Nichols dissented and observed that the compromise
still needs more work

A potential issuse with EFResolve in the case of a 2 port router with 
zero jitter on each virtual wire, apparently leading to enormous
values of the S parameter, as previously discussed on the mailing
list, was raised again.

Joel Halpern observed that both proposals (EFResolve and the "compromise")
need work, but boil down to 2 different behaviors.

Guven Mercankosk:  RFC 2598 version of EF related to VW draft,
which describes how input to network should be constrained.
Answering two points in the discussion: (1) The example of 10 
packets at a time is equivalent to an example with 10 * packet size.
(2) The original EFresolve did not say how the output rate should be
greater than the inputs. With a couple of extra statements in EFResolve,
the compromise would not be needed.

Van: "An explanation why RFC 2598 was (poorly) described in terms of
rate rather than jitter is that my background is in physics, and I am
accustomed to describing things with integrals. When I described bounding
a rate over an interval, it meant bounding the jitter. EFresolve described
this in terms of a differential, which is much more clear."

Anna Charny, responding to statement that the compromise proposal 
defines two behaviors, stated that this is not the case: it is the 
same behavior from two standpoints. She suggests that the others
should write down how VW will work using EFRESOLVE.

Consensus on direction
----------------------

The Chair indicated that the last call decision needs to be made
on the list but that he wants to take a "sense of the room".
He restated the choices as they stood following the discussion:

0/ Do nothing. The WG agrees that we are not yet ready to replace RFC 2598 
due to lack of consensus. Publish the Charny et al and EFRESOLVE drafts as 
Informational RFCs, and revisit the question in late 2001.

This option was rapidly eliminated by straw poll.

1/ The WG agrees that the work of the EFRESOLVE design team is the basis of the 
revised EF RFC, and that Charny et al should be progressed for the record as an
Informational RFC.

2/  The WG agrees that the  work of Anna Charny's group, modified as in the 
"possible compromise" message sent to the WG by Bruce Davie on Decemebr 7 
is the basis of the revised EF RFC and that the EFRESOLVE draft should be 
published for the record as an Informational RFC.

3/ The WG agrees that the two groups are talking about two different PHBs 
and that they both should be worked on independentlly, as two separate 
standards track documents.

A first straw poll showed that a small majority of those voting would be
prepared to accept two PHBs (option 3).

A second straw poll showed that if only one PHB was to be standardised
to update RFC 2598, a large majority would prefer option 2.

A third straw poll showed that a large majority would prefer only one
PHB (this is not inconsistent with the first straw poll, but it
eliminates option 3 and selects option 2).

It was however observed that anyone can submit a PHB to the WG, although
the WG charter currently excludes defining more standard PHBs.

----

_______________________________________________
diffserv mailing list
diffserv@ietf.org
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html