Subject: RE: [Diffserv] EF next steps

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 3 Aug 2000 09:50:39 -0400

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> 
> Diffservers,
> 
> In the WG meeting on August 2nd we had a clear agreement that RFC 2598
> requires clarification before we can consider advancing it to Draft
> Standard. There was also a preference in the room for not
> separating the intuitive and formal (mathematical) descriptions of EF
> into different documents. However, it was clearly impossible 
> to resolve
> the mathematical issues in such a large group and we are 
> unlikely to do
> so on the main WG mailing list.
> 
> For this reason it is intended to appoint a specific design team
> to propose a resolution of the mathematical issues for consideration 
> by the working group by a specified date. The membership of 
> the design 
> team will be announced as soon as possible.

Perhaps the rigorous mathematical definition could become an appendix? The
problem will be to make it and the words in the main document agree.

Bert
[email-masked]

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

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 03 Aug 2000 15:40:36 +0100

In message <[email-masked]>, "
Manfredi, Albert E" typed:

my take on this is that part of the math rigour required in the EF PHB spec
is about stateing the asumptions - thse assumptions possibly
include things
like
traffic source model limiations and traffic matrix assumptions
realism about topologies and buffers
classes of schedulers that the spec permits

one can imagine a spec that makes no assumptions about x,
leading to a constraint on y

given we are an open standards body, if we are to have a useful,
usable spec, we also haev to say what its for (e.g. is it for
conformance testing a PHB, or being able to compose PHBs into a
conformance testable service?, just for example - there are other
purposes for specs)

given we are an open standards outfit, we'd also like to minimise
constraitns on designers - however, there's switch, network, and
service designer. so its not obvious necessarily that minimising
cosntraints (i.e. mazximisign design freedom) for switch designer
makes life optimal.....

on th topic of appendix, i agree. but i think we _should_ get the math
and assumptions stated, and the english in the main body o the spec
should (as far as possible
correspond to it

oh, btw, i think that stating the assumptions remoevs such fuzzy
notions as "intuition".....
and they can be captured in english and math....and i thought that i
heard a lot of them stated collectievly i nthe nmeeting, so i am
pretty hopeful that we can get this done!

 >>[email-masked]

 cheers

   jon

---

From: "Brijesh Kumar" <[email-masked]>
Date: Thu, 3 Aug 2000 10:46:22 -0400

> problem will be to make it and the words in the main document agree.

I think one of the solutions would be to re-do the EF draft which
supersedes RFC 2598 by combining material from the existing EF RFC,
and Anna's draft / any other valid candidate mathematical formulation.
That way, we will have only one draft defining what EF means
intuitively and mathematically. There is already a consensus that the
current RFC 2598 by itself is not adequate.

Let us see what other views exist on this.

Cheers,

--brijesh
Ennovate Networks Inc.