Subject: [Diffserv] Status of EF Resolution effort

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 06 Oct 2000 16:30:05 -0400

The design team to resolve the pending disagreements about EF has been
conversing for a bit more than a month.  We have only two months until
the next IETF meeting, before which we intend to have completed our
task.  This message is to let you know about some of the avenues we
are exploring.

Firstly, please feel free to get in touch with either myself
([email-masked]) or the team ([email-masked]) if you feel
that we are heading off in the wrong direction, or are full of hot
air, or whatever.  We would rather know about issues ASAP.

Secondly, it would be helpful if the sets of authors would identify
someone with whom we can talk about what your intentions /
understandings are so that we make sure not to completely misrepresent
your work.  Please send contact information to me.

Thirdly, none of the documents I am refering to here are internet
drafts.  They are just notes that we have exchanged.  When we get far
enough to have an Internet Draft available, I will let you know
immediately.

We have been wrestling with several dimensions.
We have put together a note that summarizes for ourselves our
understanding of the proposals and problems on the table.
We have raised some interesting questions (see next paragraph).
We are trying to craft solutions (see following paragraph).

The questions tend to revolve around two issues.  One set of issues we
have been discussing revolve around what terms it is easiest for us to
understand / talk about / define EF.  This relates to efforts to
understand the goal of the behavior, but is not equivalent to it.  We
have gotten into discussions of rate, delay, delay variation, and the
precision with which these can be mandated, etc.  (Issues that I am
certain the teams of authors have wrestled harder and have more
experience than we do, but we are trying our best.)
One of the interesting questions that has been raised in the team is
how to deal with traffic dependency.  The proposals on the table all
seem to have either implicit or explicit dependencies on some non-EF
traffic model (the EF traffic models are pretty explicit and do not
represent an issue here.)  However, the IETF does not have an agreed
traffic model for us to use.  There is even some experimental evidence
indicating that traffic behavior can have a noticeable effect on the
deliver of EF-like services, even when one is very careful.  So we are
wrestling with either trying to remove such dependency, or trying to
be more explicit about it.

In terms of crafting solutions, we are persuing several paths at
once.  Some of these will not make people happy.  If we can not find a
more acceptable solution, we may have to recommend (the final answer
will be up to the working group) that we move all of this work to
experimental.  We are trying to do better than that.  Another proposal
on the table is to craft a definition in which the normative (MUST)
definition is fairly loose and possibly even not particularly
mathematical.  And then add informative mathematics describing systems
that one might build to comply with this.  Our concern with this
approach is that it may not be particularly helpful in then building
PDBs out of the PHB.  We are also examining alternative
charactizations to see if we can find one that seems to work for the
goals that were laid out.

In conjunction with this, we would appreciate hearing from any
providers who would like to define a PDB built from an EF PHB as to what
characteristics you think would help you make use of the definition of
the PHB.

Yours,
Joel M. Halpern, chair EF problem resolution design team

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: "Bill Courtney" <[email-masked]>
Date: Sun, 8 Oct 2000 17:55:27 -0700

Joel,

Please see comments in-line.

Bill Courtney

 <snip>
> be more explicit about it.

I'm unclear on why you want to deal with traffic dependency. The original
definition of EF in RFC 2598 and the redefinition in
draft-charny-ef-definition-00.txt
give worst-case, gotta-do-it behavior regardless of the presence of other
traffic. True, if only EF traffic is present it may be forwarded faster than
required, but no matter what is going on, it may not be forwarded slower
than
required. That is, an EF definition should state what is acceptable
worst-case
per-hop behavior.

It seems to me that issues of rate, delay, and delay-variation are
important as they apply to microflows (which are beneath the scrutiny of any
DiffServ PHB, including EF) across a domain or from end to end (which is
beyond
the scope of any DiffServ PHB, including EF). I'm not suggesting that
traffic
dependency issues are out-of-bounds for the panel (even if I were at liberty
to make such a suggestion). I'm suggesting that EF is meant to be a service
for high-priority stuff, and that the only effect other traffic is going to
have
on it is to keep it running at something between the line rate and the
minimal
permissible rate (and probably fluctuating between the two in unpredictable
ways).
I doubt that any more sophisticated analyses of traffic will further you in
your charter. Where do you expect that your wrestling will take you?

> goals that were laid out.

Regarding mathematics: I think it would be a mistake to pre-determine
the level of mathematical content that should be embodied in the PHB
definition. I also think that last summer's discussion of the proper role
of mathematics in the definition was a misguided waste of time. In
the energetic discussion of RFC 2598 and the draft-charny redefinition,
most everyone seemed to have subscribed to an unspoken belief that
the redefinition was *mathematical.* In fact, it was NOT particularly
mathematical. True, it involves addition, division, a maximum and a
minimum, but c'mon, what doesn't? Not counting memory reads and writes,
you could code the thing in about 10 Ops. How mathematical could
it be? The redefinition was implementable and it was exact, but
mathematical?

I think that the surrounding text in the draft convinced readers
that anything that had so much analysis around it must, itself, be
mathematical. That text was written to demonstrate a couple of things:

   1) The redefinition can be implemented on servers employing any of
      a large variety of service disciplines
   2) Familiar end-to-end analysis techniques can be applied to the
      redefinition

Again, making suggestions where they may not be welcome, I would
suggest that the panel focus on the issues of whether the ultimate
EF definition is

    1) Appropriate (I.e., does it behave the way we would want a
       "Come hell or high water, I'm gonna forward this stuff" PHB
       to act) and
    2) Implementable (I.e., can the PHB actually be realized exactly
       without handwaving, nudges & winks, or "you know what I mean"s
       attached to it? Is the definition simple enough that reasonable
       implementers will understand what is meant by it? Is the
       processing and memory burden demanded by the definition tolerable
       to implementers?)

Whatever is necessary to come up with a clear and crisp expression of
such a definition should be used. If some math slips in, well, ..., no
one is perfect. :-)

> Joel M. Halpern, chair EF problem resolution design team

Best of luck to the panel. I hope that you are able to cut through the
emotional fog that arose mid-summer.