Subject: RE: Isssue #0 [was Re: [Diffserv] Comments on draft-charny-ef-definition-00

From: Bill Courtney <[email-masked]>
Date: Fri, 28 Jul 2000 10:17:37 -0700

Brian,

I agree. If the consensus is "No. Rigor is not required AND, in
particular, not important in this instance, then we can skip 1)
through 6) and move on to other topics ... or to lunch."

Regards,
Bill Courtney
TRW, Network System Engineering
-----

Only the mediocre person is always at his best.
                                             Tom & Ray Magliozzi

---------------------------------------------------------------------

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, July 28, 2000 9:30 AM
> To: Bill Courtney
> Cc: [email-masked]
> Subject: Isssue #0 [was Re: [Diffserv] Comments on
> draft-charny-ef-definition-00
> 
> 
> Bill,
> 
> I would like to add a preliminary issue to your list, which I think 
> is the first question to be answered by the WG:
> 
> 0) Is it a requirement that PHB definitions are adequate to perform
> mathematically rigorous conformance testing of implementations,
> or is it sufficient that they give a general, intuitive
> description of the behavior of an implementation?
> 
> I've re-read the relevant sections of RFCs 2474 and 2475 and they
> do not answer this question, despite the use of the word
> "conformance" in 2475, Section 3, paragraph G.9. 
> 
>    Brian
> 
> ...
> > 
> > Issues:
> > 
> > 1) Does this definition capture the intuition of RFC 2598? If
> > not, where does it fall short, or how does it utterly fail? Is
> > there a killer arrival pattern that makes mincemeat of the
> > definition? Does it persist in sending EF bits when it should
> > be dropping packets? If so, what drop criteria should be added,
> > or should reference to RFC 2598's drop criteria be made?
> > 
> > 2) Does the definition support the development of PDBs that
> > are likely to be based on EF? In particular, does it support
> > VW (or whatever VW becomes once that separate discussion
> > concludes)?
> > 
> > 3) Is the definition too complicated? Is it too hard to
> > understand, especially will it be too hard for implementers
> > to use? What simpler definition would suffice?
> > 
> > 4) Is the definition just nit-picking? Is the decrease in
> > ambiguity and are the added benefits (such as E and the
> > lifting of the 50% configured rate limitation) worth
> > the bother?
> > 
> > 5) Is E useful? Does it offer a figure-of-merit that
> > implementers, PDB definers, end-to-end service providers,
> > and other network engineers will use? Or is it just some
> > piece of mumbo-jumbo of interest only to researchers
> > interested in cranking out another paper or two? Does it
> > encourage laxity in router implementation and admit crummy
> > service into the EF fold? Is this laxity a problem if you
> > have to advertise how lax you've been, or is it a spur to
> > do better? (Is that last question so far out of bounds for
> > the IETF that Brian will special deliver a reprimand to me?)
> > 
> > 6) Is the definition sufficiently different from the RFC 2598
> > defintion that the draft should be reformed into a new, stand-
> > alone PHB?
> > 
> > Thanks,
> > Bill Courtney
> > TRW, Network System Engineering
> > 
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www1.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> 

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