Subject: RE: AW: [Diffserv] about the concern of a rate loss in the defin ition ofdraft-charny-ef-definition-00

From: Jon Bennett <[email-masked]>
Date: Thu, 10 Aug 2000 14:48:03 -0400

> It's not just the spirit, it is the formal definition of a PHB. A PHB 
> specification describes the behavior of a node for a BA, i.e. 
> the outbound stream of packets carrying  the corresponding DSCP, 
> regardless of their origin, of merging within the node, or of 
> their attribution to different microflows.
> 
> Which tells you that any assertions about rate, latency, or jitter
> should refer to the BA, not to the individual flows within the BA.

I find this to be a strange comment given that;

a) The discussion on this thread has been almost totally about BA rate, 
  jitter, etc and not about individual flow jitter.

b) The VW draft spends almost all of its time discussing per flow 
   jitter and you didn't raise this complaint when that draft was
   presented.

c) We have to discuss what assertions can be made about the 
   behavior of individual flows in the aggregate because we can 
   only build on the PHB if we can say something about what 
   will happen to the microflows in the aggregate.

> I'm glad you brought this up, because I was wondering last 
> night whether
> people had lost sight of it.
> 
>   Brian
> 
> P.S. this doesn't stop vendors trying to do better, but it does
> limit what goes in PHB definitions.

It is probably worth pointing out that an implication of this last 
comment, which is also more explicitly stated in 
draft-ietf-diffserv-model-04 is that the statement that microflow
awareness can not be a *requrirement* of a PHB is very different 
from saying it is ok if the PHB definition in effect *prohibits* 
microflow awareness.

I have heard a number of comments of the form "why don't we just
make the definition 'a packet can be delayed by no more than X?'"
such a definition would in effect prohibit a router from being 
microflow aware. 

The reason that a definition with a single fixed 
latency/jitter/etc term for each *packet* would prohibit microflow
awareness can be seen in this example. Suppose the EF aggregate 
traffic contained some high rate VW traffic and some much lower 
rate VoIP traffic, a good way to serve this traffic would be to 
give higher precedence/weight to the VW traffic than to the VoIP 
traffic. 

This would give the VW traffic a lower jitter/latency which it 
would want and the VoIP traffic a higher jitter/latency which 
with a much looser jitter bound it could easily handle. If a 
fixed jitter/latency requirement were imposed which could support 
the VW requirements then this approach would not work or would 
only work at a lower traffic load. 

The VW PDB draft mentions ways of dealing with microflows in 
the aggregate with different rates, and that one solution would 
be to have different DSCP's for different rates. This statement 
assumes FIFO service of the aggregate traffic. If a router was 
microflow aware it could service packets belonging to different 
rate microflows.... differently. And thus address this issue 
without the need to consume multiple DSCP's, the need to 
coordinate the rate mappings between ISPs or between ISPs 
and their customers, etc..

jon

_______________________________________________
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: Thu, 10 Aug 2000 14:52:37 -0500

Jon,

I didn't think I was saying anything contentious.

>   jitter, etc and not about individual flow jitter.

Mostly yes, but a few times it seemed to me people were not clearly
separating the concepts. If that's not the case so much the better.

>    jitter and you didn't raise this complaint when that draft was

I want to consider this comment carefully, not so much w.r.t. VW but
for the general PDB definition. I was referring very specifically
to PHBs of course.

>    will happen to the microflows in the aggregate.

Yes, when describing PDBs that is certainly a valid point. But it's
explicitly excluded from PHB definitions by RFC 2474/5, specifically
to avoid a *requirement* for per microflow state (but see below).

> from saying it is ok if the PHB definition in effect *prohibits*

Absolutely. That's been agreed since the interim meeting in Cambridge.

> and their customers, etc..

My opinion is that this is a domain we should leave to
vendors and the marketplace, at least in our present state
of knowledge.

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]