Subject: RE: [Diffserv] Comments on draft-ietf-diffserv-vw-pdb

From: Jon Bennett <[email-masked]>
Date: Wed, 26 Jul 2000 12:52:29 -0400

> I am totally serious. Let me quote what Van said elsewhere on 
> this thread:

I see so if Van says something then it must be true?

> > To the best of my knowledge, the state of the art in queuing theory is
very, 
> very far from the point where one could hope to get a useful analytic 
> model of a real router so we made no attempt to *specify* the behavior.

I would be very amused if this statement were correct. If it were then there
would be no place for any statistical discussion about the performance of
Diffserv traffic. Since people (Van included) do put forth statistic
arguments based on modeling of routers (what else do you call the
simulations includes in both RFC 2598 and the VW draft?) either this
statement is incorrect or those simulations are without merit (If you think
you can model a router well enough to simulate it then you can model it well
enough to make statistical analysis).

> We can't correctly model routers, so maybe we should give up the
> pretence that describing a single scheduling algorithm mathematically
> tells us anything much about the total performance of a node. 

With all due respect (which is becoming less and less as this goes on),
speaking as one who designs and builds *modern* *hardware-based* routers, it
is simply a fact that the description of a scheduling algorithm (which is
not by the way what we were doing) can completely describe the behavior of a
node. Period. The fact that there are routers for which this is not the case
does not contradict this. 

> I've seen
> people use the word "conformance" and the word "guarantee" in this
> discussion; this is thinking from the ATM/Telco world and it isn't
> going to get us very far in the Internet.

Given that there is plenty of Internet2 traffic going over the vBNS, and
that vBNS traffic runs as an overlay on top of ATM switches (which I
designed, thank you) I'm not sure that mudslinging against ATM on this
subject does much more than display narrow mindedness.

And given that much of the serious core Internet equipment being built or
designed draws very heavily from the Telco world and its 'guarantees' and
'conformance' requirements, I would also recommend against arguments of the
form 'Its fine if we write documents for which it is not possible to
determine if a piece of equipment does what the document says'. 

In fact I would like to propose the following question to you *as* the
chair, 'yes' or 'no' 

"do you believe that it is ok for the IETF to approve standards for which it
is not possible to determine if a piece of equipment conforms to the
standard?"

I dare you to answer 'yes'.

Jon C. R. Bennett
Chief Engineer
RiverDelta Networks 
3 Highwood Drive
Tewksbury, MA  01876
978.858.2300/2361 (direct)
978.858.2399 (Fax)

   -export-a-crypto-system-sig -RSA-3-lines-PERL

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Jul 2000 14:16:09 -0500

> I see so if Van says something then it must be true?

Well, it must be worth serious consideration at least.
> enough to make statistical analysis).

This is what I find debatable. Until I see simulations and analyses reported
where the traffic models are self-similar, at least. Poisson traffic models
are unrealistic but my impression (and I am *not* a mathematician so this is
only an impression) is that only Poisson models have proved tractable to
analysis so far. And the popular simulation tools all model Poisson traffic
to my knowledge, so they don't simulate reality. 

So it is my belief that whatever analysis and simulation we can do today
is not going to be an accurate model of reality (or at best within
a substantial margin of error of 10 or 20%) and we have to be very careful
about arguing from such analyses and simulations rather than from boundary
conditions. Indeed that applies to both types of EF.

> does not contradict this.

Let's grant that. Since the IETF's job is to write vendor-independent
specifications, the fact that there are also routers whose total behaviour
is *not* defined by a single scheduling algorithm is equally relevant;
we have to write specifications that work in either case.

> subject does much more than display narrow mindedness.

What I was getting at was ATM other than CBR. Actually the most successful
EF deployment tests I am aware of have been carried out over ATM. Anyway,
I wasn't mudslinging. I was saying that the kind of conformance criteria
that Telcos have considered relevant in the ATM world are irrelevant
in the Internet. 

> 'conformance' requirements, 

I can only say that I think this is an error. We do need some types
of guarantees to provide high service quality, but not ones that
remove any scope for flexibility in queuing mechanisms and tradeoffs.
Internet applications, including real time applications, simply
aren't that sensitive. We are getting off topic here, but I want to
be clear that there is a philosophical difference here.

> I would also recommend against arguments of the

As I said in another message, the IETF doesn't specify or verify conformance.
We specify and verify interoperability and that is a different and 
less onerous thing.

> is not possible to determine if a piece of equipment conforms to the

That's a slightly different question from the one I just answered implicitly.
In general the IETF *only* specifies wire protocols, for which 
interoperability can be verified objectively. We have generally avoided
specifying internal behaviours excepted as manifested by wire protocols,
precisely because you can't test internal behaviours by interoperability
testing. The IETF goal is to specify standards that can be validated solely
by interoperability tests. 

RFC 2474 states:

>    The behavioral characteristics of a PHB are to be standardized, and
>    not the particular algorithms or the mechanisms used to implement
>    them. 

In other words we have no business in any PHB definition attempting
to define scheduling algorithms as part of the normative text, and
certainly no business attempting to define conformance criteria
with such algorithms. That's why, for example, the markers for AF
are separate from RFC 2597. And probably most of the current
discussion and some of the current content of 2598 should not
be in a standards track document at all. Specifically, there
is a case for removing section 2.2 and the Appendix.

> I dare you to answer 'yes'.

My answer is that the question is immaterial because the
IETF does not consider conformance as a criterion for
standards work.

   Brian